EK-DMV11-TM-001 



DMV11 

Synchronous Controller 
Technical Manual 



mmm 



EK-DMV11-TM-001 



DMV11 

Synchronous Controller 
Technical Manual 



PREPARED BY EDUCATIONAL SERVICES 
OF 

DIGITAL EQUIPMENT CORPORATION 



1st Edition, September 1981 



Copyright ® 1981 by Digital Equipment Corporation 

The material in this manual is for informational purposes and is 
subject to change without notice. 

Digital Equipment Corporation assumes no responsibility for any 
errors which may appear in this manual. 



This document was set on DIGITAL'S DECset-8000 computerized 
typesetting system. 



The following are trademarks of Digital Equipment Corporation, 
Maynard, Massachusetts: 



Printed in U.S.A. 



DIGITAL 
DEC 



DECsystem-10 

DECSYSTEM-20 

DIBOL 

EDUSYSTEM 

VAX 

VMS 



MASSBUS 
OMNIBUS 



DECUS 
UNIBUS 



PDP 



OS/8 
RSTS 
RSX 
IAS 



CONTENTS 



Page 

PREFACE 

CHAPTER 1 INTRODUCTION 

1.1 INTRODUCTION 1-1 

1.2 INTRODUCTION TO MULTIPOINT 1-1 

1.3 DMV1 1 GENERAL DESCRIPTION 1-1 

1.4 STANDARD APPLICATIONS 1-3 

1.5 DMV1 1 SYSTEM OPERATION 1-3 

1.6 COMMAND/RESPONSE STRUCTURES 1-4 

1.6.1 Input Commands 1-4 

1.6.2 Output Responses 1-6 

1.7 PROTOCOL SUPPORT 1-6 

1.7.1 Data Messages 1-6 

1.7.2 Control Messages 1-6 

1.7.3 Maintenance Messages 1-6 

1.8 GENERAL SPECIFICATIONS 1-8 

1.8.1 Environmental Specifications 1-8 

1.8.2 Electrical Specifications 1-8 

1.8.3 Performance Specifications 1-8 

CHAPTER 2 INSTALLATION 

2.1 INTRODUCTION 2-1 

2.2 UNPACKING AND INSPECTION 2-1 

2.3 INSTALLATION CONSIDERATIONS 2-1 

2.4 PREINSTALLATION CONSIDERATIONS 2-2 

2.4.1 Device Placement 2-6 

2.4.2 System Requirements 2-6 

2.5 INSTALLATION 2-9 

2.6 DMV1 1 SYSTEM TESTING 2-10 

2.6.1 Functional Diagnostic Testing 2-10 

2.6.2 DEC/X1 1 System Exerciser 2-10 

2.6.3 Final Cable Connections 2-10 

2.6.4 DMV11 Link Testing 2-10 

CHAPTER 3 COMMAND AND RESPONSE STRUCTURES 

3.1 INTRODUCTION 3-1 

3.2 COMMAND STRUCTURE 3-1 

3.2.1 Control and Status Registers 3-1 

3.2.2 Input Commands Overview 3-5 

3.2.3 Output Responses Overview 3-5 

3.3 DMV1 1 INPUT COMMANDS 3-6 

3.3.1 Microprocessor Control / Maintenance Command 3-6 

3.3.2 Mode Definition Command 3-6 



iii 



CONTENTS (Cont) 



Page 

3.3.3 Control Command 3-9 

3.3.4 Buffer Address/ Character Count (BA/CC) Command 3-16 

3.4 DMV1 1 OUTPUT RESPONSES 3-18 

3.4.1 Buffer Disposition Response 3-19 

3.4.2 Control Response 3-20 

3.4.3 Information Response 3-26 

3.5 TSS/GSS ACCESS 3-26 

CHAPTER 4 PROGRAMMING TECHNIQUES 

4.1 INTRODUCTION 4-1 

4.2 COMMAND /RESPONSE DISCIPLINE AND HANDSHAKING 4-1 

4.2.1 Command Discipline 4-2 

4.2.2 Retrieving Responses 4-3 

4.2.3 CSR Interface Interactions 4-3 

4.3 DMV11 START-UP 4-3 

4.3.1 Configuration Procedure 4-4 

4.3.2 Specifying User-Defined Parameters 4-4 

4.3.2.1 Specifying TSS Parameters 4-6 

4.3.2.2 Specifying GSS Parameters 4-1 1 

4.3.3 Protocol Operation 4-13 

4.4 CRITERIA FOR DETERMINING COMMUNICATIONS 

LINK PARAMETERS 4-13 

4.4.1 Setting the Selection Interval Timer 4-14 

4.4.2 Setting the Babbling Tributary Timer 4-16 

4.4.3 Setting the Streaming Tributary Timer 4-16 

4.5 ERROR COUNTER ACCESS... 4-17 

4.5.1 Reading the Counters 4-17 

4.5.2 Counter Skew 4-17 { 

4.6 ERROR RECOVERY PROCEDURES 4-17 

4.6.1 Recovery from Network Errors 4-18 

4.6.1.1 Recovery from Threshold Errors. 4-18 

4.6.1 .2 Recovery from Babbling and Streaming Tributary Errors 4-18 

4.6.2 Recovery from Procedural Errors 4-18 

4.6.2.1 Recovery from a Nonexistent Memory Error 4-18 

4.6.2.2 Recovery from a Receive Buffer Too Small Error 4-19 

4.6.2.3 Recovery from a Queue Overflow Error 4-20 

4.7 BOOTING A REMOTE STATION 4-20 

4.7.1 Steps Leading to a Remote Load Detect Boot 4-21 

4.7.2 Steps Leading to a Power-On Boot 4-21 

4.7.3 Steps Leading to an Invoke Primary MOP Boot 4-22 

4.7.4 DM VI 1 Switch Settings for the Boot Functions 4-22 

4.7.4.1 Switch Settings for the Power-On Boot Function 4-22 

4.7.4.2 Switch Settings for the Invoke Primary MOP Boot Function 4-22 

4.7.4.3 Switch Settings for the Remote Load Detect Boot Function 4-23 

4.8 MAINTENANCE REGISTER EMULATION 4-23 



iv 



CONTENTS (Cont) 



Page 

CHAPTER 5 ASPECTS OF DMV1 1 MICROCODE OPERATION 



5.1 INTRODUCTION 5-1 

5.2 DMV1 1 POLLING ALGORITHM 5-1 

5.2.1 Calculating Polling Urgency 5-2 

5.2.2 Criteria for Determining Polling Parameters 5-6 

5.2.2. 1 Determining a Value for DELTA T 5-6 

5.2.2.2 Determining Values for Q and R 5-7 

5.2.2.3 Determining a Value for Poll Delay 5-8 

5.2.2.4 Determining a Value for DEAD T 5-8 

5.3 ERROR COUNTERS 5-8 

5.3.1 Data Link Error Counters 5-9 

5.3.1.1 Data Errors Outbound 5-9 

5.3.1.2 Data Errors Inbound 5-11 

5.3.1.3 Local Reply Timeouts 5-11 

5.3.1.4 Remote Reply Timeouts 5-11 

5.3.1.5 Local Buffer Errors 5-12 

5.3.1.6 Remote Buffer Errors 5-12 

5.3.1.7 Selection Timeouts 5-12 

5.3.1.8 Data Messages Transmitted 5-12 

5.3.1.9 Data Messages Received 5-12 

5.3.1.10 Selection Intervals 5-13 

5.3.2 Station Error Counters 5-13 

5.3.2.1 Remote Station Errors 5-13 

5.3.2.2 Local Station Errors 5-13 

5.3.2.3 Global Header Block-Check Errors 5-14 

5.3.2.4 Maintenance Data Field Block-Check Errors 5-14 

5.3.3 Threshold Error Counters 5-14 

5.3.3.1 Transmit Threshold Errors 5-14 

5.3.3.2 Receive Threshold Errors 5-15 

5.3.3.3 Selection Threshold Errors 5-15 

5.4 DMV1 1 MICROCODE INTERNAL DATA BASE OVERVIEW 5-15 

5.4.1 Linked Lists 5-15 

5.4.1.1 The Free Linked List 5-16 

5.4. 1 .2 The Response Linked List 5-18 

5.4.1.3 Buffer Linked Lists 5-18 

5.4.2 Slot Mapping Table 5-19 

5.4.3 TSS and GSS Structures 5-19 

5.4.3.1 The Global Status Slot (GSS) 5-19 

5.4.3.2 Tributary Status Slots (TSS) 5-19 

CHAPTER 6 TECHNICAL DESCRIPTION 

6.1 INTRODUCTION 6-1 

6.2 LOGIC DESCRIPTION 6-1 

6.2.1 Control and Address Decoder 6-1 



v 



CONTENTS (Cont) 



Page 

6.2.1.1 The 6502 Microprocessor 6-1 

6.2.1.2 Timing Circuits 6-2 

6.2.1.3 6502 Data and Address Interface 6-2 

6.2.1.4 Address Decoders 6-3 

6.2.2 I/O Data Bus 6-3 

6.2.2.1 USYRT 6-3 

6.2.2.2 USYRT Control 6-3 

6.2.2.3 Line Interface Control 6-6 

6.2.3 DMV11 Memory 6-6 

6.2.3.1 ROM Control Storage 6-6 

6.2.3.2 RAM 6-6 

6.2.3.3 NPR In/Out Registers 6-6 

6.2.4 LSI-1 1 Bus Interface 6-7 

6.2.4. 1 LSI-1 1 Bus DAL Interface 6-7 

6.2.4.2 CSR Controller 6-8 

6.2.4.3 Interrupt Controller 6-8 

6.2.4.4 NPR Controller 6-9 

6.2.5 Memory and Reset Control 6-9 

6.2.6 Modem Interface 6-9 

6.2.7 Integral Modem 6-10 

6.2.7.1 Receive 6-10 

6.2.7.2 Transmit 6-10 

CHAPTER 7 SERVICE 

7.1 SCOPE 7-1 

7.2 MAINTENANCE PHILOSOPHY 7-1 

7.3 TROUBLESHOOTING TECHNIQUES FOR MULTIPOINT 7-1 

7.3.1 Approach 7-1 

7.3.2 Error Counters 7-7 

7.3.2. 1 Data Link Error Counters 7-7 

7.3.2.2 Station Error Counters 7-1 1 

7.3.2.3 Threshold Error Counters 7-12 

7.3.3 Error Counter Analysis 7-13 

7.4 MAINTENANCE 7-16 

7.4.1 Maintenance Mode 7-16 

7.4.2 Standard Operating Mode 7-16 

7.5 PREVENTIVE MAINTENANCE (PM) 7-17 

7.6 CORRECTIVE MAINTENANCE 7-17 

7.6.1 DM V 1 1 Static Logic Tests Parts 1 and 2 7-17 

7.6.2 DMV1 1 Static Logic Tests Parts 3, 4, and 5 7-19 

7.6.3 DMV1 1 Functional Diagnostic 7-21 

7.6.4 DMV1 1 Microdiagnostic Error Reporting 7-21 

7.6.5 Data Communications Link Test Program (DCLT) 7-21 

7.6.6 DEC/X1 1 DMV1 1 Modules 7-25 

7.6.6.1 DMD* 7-25 



vi 



CONTENTS (Cont) 



Page 

7.6.6.2 DME* 7-26 

7.6.7 Soft Error Reports Under DEC/X1 1 7-27 

APPENDIX A DDCMP IN A NUTSHELL 

A.l DDCMP A-l 

A. 1 . 1 Controlling Data Transf ers A-l 

A. 1.2 Error Checking and Recovery A-l 

A. 1.3 Character Coding A-2 

A. 1 .4 Data Transparency A-2 

A. 1.5 Data Channel Utilization ... A-2 

A.2 PROTOCOL DESCRIPTION A-2 

A. 3 MESSAGE FORMAT A-4 

APPENDIX B FLOATING DEVICE AND VECTOR ADDRESSES 

B. l FLOATING DEVICE ADDRESSES B-l 

B.2 FLOATING VECTOR ADDRESSES B-l 

B. 3 EXAMPLES OF DEVICE AND VECTOR ADDRESS ASSIGNMENT B-5 

APPENDIX C MODEM CONTROL REGISTER FORMATS 

C. 1 MODEM CONTROL REGISTER FORMATS C-l 

C. 2 RS-449 VERSUS RS-232-C C-4 

APPENDIX D MODEM CONTROL 

D. l MODEM CONTROL D-l 

D. 1 . 1 Hardware Modem Control D-l 

D.l. 2 Modem Control Implemented by the DM VI 1 Microcode D-l 



FIGURES 

Figure No. Title Page 

1 - 1 DM V 1 1 s Used in Point-to-Point Applications 1-4 

1-2 DM VI Is Used in Multipoint Applications 1-5 

1- 3 General Summary of DMV 11 Command/ Response Structure 1-7 

2- 1 Local Network Topology 2-3 

2-2 Remote Network Topology 2-4 

2-3 M8053 Switch Locations 2-7 

2-4 M8064 Switch Locations 2-8 

vii 



FIGURES (Cont) 



Figure No. Title Page 

2-5 DM V 1 1 Switch Selectable Features 2-13 

2-6 Test Connector Insertion for the M 805 3 2-16 

2-7 Test Connector Insertion for the M8064 2-17 

2-8 DMV1 1 Test Connectors 2-18 

2-9 DM VI 1 Cable Drawings 2-22 

2-10 DMV1 1 Remote System Cabling Diagram 2-25 

2-1 1 DM VI 1 to DM VI 1 Integral (Local) Modem Cabling Diagram (Point-to-Point) .. 2-26 

2-12 Half-Duplex Multipoint Network (Control Station End Node) 2-27 

2-13 Full-Duplex Multipoint Network (Control Station End Node) 2-28 

2- 14 Full-Duplex Multipoint Network (Control Station Inner Node) 2-29 

3- 1 DMV1 1 CSRs Byte and Word Symbolic Addresses 3-2 

3-2 Fixed and Variable Formats for Commands and Responses 3-2 

3-3 Microprocessor Control/ Maintenance Command Format 3-6 

3-4 Initialization of the DM VI 1 3-7 

3-5 Mode Definition Command Format 3-8 

3-6 Control Command Format 3-9 

3-7 Buffer Address/Character Count Command Format 3-17 

3-8 Buffer Disposition Response Format 3-19 

3-9 Control-Out Command Format 1 8-Bit Mode 3-26 

3- 10 Information Response Format 3-27 

4- 1 CSR Interface Control Bits 4-2 

4-2 CSR Access Window 4-4 

4- 3 DM VI 1 Maintenance Loop Command Format 4-24 

5- 1 Interrelationship Between Polling Parameters Q, R, and DELTA T 5-3 

5-2 Relationship Between Polling Parameters Q, R, and the 

Minimum Polling Interval 5-4 

5-3 Relationship Between the Default Values for Q and R for the 

Three Polling Activity Levels 5-5 

5-4 State Diagram of Polling State Transitions 5-7 

5-5 Data Link and Threshold Error Counters 5-10 

5-6 Station Error Counters 5-11 

5-7 Data Memory Map 5-16 

5-8 DMV11 Linked List Structure Format 5-17 

5-9 Standard Link Block 5-18 

5-10 Global Status Slot. 5-21 

5- 1 1 Tributary Status Slot 5-23 

6- 1 DMV1 1 Block Diagram 6-2 

6-2 Control and Address Decoder 6-3 

6-3 I/O Data Bus 6-4 

6-4 USYRT Timing Diagram 6-5 

6-5 Data Memory Organization 6-7 

6-6 LSI-1 1 Bus Interface 6-8 

6-7 Integral Modem Receive 6-11 

6- 8 Integral Modem Transmit 6-12 

7- 1 Example of a Typical Isolation Flow Diagram 7-2 

7-2 Data Link and Threshold Error Counters 7-8 

. 7-3 Station Error Counters , 7-9 



viii 



FIGURES (Cont) 



Figure No. Title Page 

7-4 Full-Duplex Seven Tributary Multipoint Network 7-14 

A-l DDCMP Data Message Format A-l 

A-2 DDCMP Message Format in Detail A-3 

B-l UNIBUS and LSI-1 1 Address Map B-2 

D-l Flow Diagram Symbology D-4 

D-2 Modem Control (Start) D-5 

D-3 Modem Control (Transmit) D-6 

D-4 Modem Control (Transmit 2) D-7 

D-5 Modem Control (Receive) D-8 

D-6 Modem Control (Modem Status) D-9 

D-7 Modem Control (Call Timer) D- 1 

D-8 Modem Control (Shutdown) D-l 1 



TABLES 

Table No. Title Page 

1- 1 DMV11 Options 1-3 

2- 1 DMV1 1 Option Packing List 2-2 

2-2 Typical Host Options of a Bell 208 A Data Set (4800 b/s) 

Full-Duplex Operation , 2-5 

2-3 Typical Tributary Options of a Bell 208 A Data Set (4800 b/s) 

Full-Duplex Operation 2-5 

2-4 DM VI 1 Voltage Chart 2-6 

2-5 Device Address Selection 2-1 1 

2-6 Vector Address Selection 2-12 

2-7 Cable Description 2-14 

2- 8 Modem Option Jumper Functions 2-30 

3- 1 SEL0 Bit Functions 3-2 

3-2 BSEL2 Bit Functions 3-4 

3-3 Input Command Codes 3-5 

3-4 Mode Field Codes and Functions 3-8 

3-5 SEL6 Control Command Functions 3-10 

3-6 Request Key Field Definitions (Control Command) 3-14 

3-7 Output Codes 3-21 

3- 8 Return Keys for Information Response 3-27 

4- 1 Diagnostic Error Codes 4-5 

4-2 User-Defined TSS Parameters 4-7 

4-3 User-Defined GSS Parameters 4-12 

4-4 Recommended Selection Interval Timer Values 4-15 

4-5 Mode Switch Settings 4-23 

4-6 Maintenance Command Functions BSEL2 Bits 0-3 4-25 

ix 



TABLES (Cont) 



Table No. Title Page 

7-1 DMV11 Diagnostics 7-18 

7-2 DM VI 1 Static Logic Test Part 1 Diagnostic Summary 7-18 

7-3 DMV1 1 Static Logic Test Part 2 Diagnostic Summary 7-19 

7-4 DM VI 1 Static Logic Test Part 3 Diagnostic Summary 7-19 

7-5 DM VI 1 Static Logic Test Part 4 Diagnostic Summary 7-20 

7-6 DM VI 1 Static Logic Test Part 5 Diagnostic Summary 7-21 

7-7 DM VI 1 Functional Diagnostic Summary 7-23 

7-8 Microdiagnostic Error Codes 7-24 

B-l Floating CSR Address Devices B-3 

B-2 Floating Interrupt Vector Devices B-3 

D-l DMV11 Modem Control Functions D-2 



x 



PREFACE 



This manual describes in detail the installation requirements, programming considerations and tech- 
niques, microcode operation, technical functions, and servicing procedures, including diagnostic sup- 
port, for the DM VI 1 Synchronous Controller. A variety of appendices are also provided to supplement 
the above. 

Other publications which support the DMV11 Synchronous Controller are: 

• DMV11 Print Set (MP-00942) 

• Electronic Industries Association (EIA) Specifications 

• DIGITAL Data Communications Message Protocol (DDCMP) Specifications (AA-D599A- 
TC) 
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CHAPTER 1 
INTRODUCTION 



1.1 INTRODUCTION 

The multipoint DDCMP-DMV11 Intelligent Communications Synchronous Line Controller is a device 
which provides efficient high-speed synchronous communications for distributed networks. The 
DMV11 uses LSI- 11 CPUs as control or tributary stations, while requiring a minimum of main CPU 
resources. This manual provides detailed information necessary for installing and operating the 
DMV11. 



1.2 INTRODUCTION TO MULTIPOINT 

Point-to-point configurations are practical when the message rate of the terminals is high. In many 
cases, however, the message rate of the terminals is very low even though the bit rate may be quite 
high. In these cases, sharing a transmission line can significantly reduce the cost and improve the effi- 
ciency of a communications network. 

Various techniques are used to share transmission lines to improve their utilization. One of these tech- 
niques is the use of multipoint lines. In multipoint operation, a single line can be shared among many 
nodes. Each node is a station and has a unique address. One station in the network is always designated 
as the control station while the remaining stations are designated as tributary stations. Because all sta- 
tions are connected to the same line, no two tributary stations may transmit at the same time, and each 
station must have a means of recognizing which messages it is meant to receive. The address field of the 
message header identifies the station to receive the message. The control station governs sharing of the 
line by means of polling in order to authorize transmission to the control station. In a polling operation 
the tributaries are in effect asked one by one whether they have anything to transmit. To accomplish 
this, the control station sends a polling message with a unique tributary address down the line. The 
station which recognizes the address responds by sending data or by sending a positive response. 

Tributary stations can only transmit to the control station and only in response to a polling message 
from the control station. Transmission between tributaries is not allowed as all message traffic must be 
routed through the control station. Control stations on the other hand may transmit to any tributary at 
any time if the communicating stations are in full-duplex. In fact, multiple messages for different desti- 
nations (tributaries) can be sent serially by the control station. Each tributary station then, in turn, 
examines the address and accepts only those messages it is meant to receive. 

The use of communication lines can be maximized by using full-duplex capabilities at the control sta- 
tion to accommodate many tributary stations on a full-duplex line. In this mode, the control station 
keeps the lines full by sending to one or more tributary stations, while at the same time receiving from 
another tributary station. 



1.3 DMV11 GENERAL DESCRIPTION 

The DMV11 is a high-performance line controller which operates at speeds up to 56K b/s. It accom- 
plishes this by doing DMA transfers. 
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There are three available options and they are outlined below. 

The DM VI 1-AA consists of: 

• An M8053-MA microcontroller/line unit (a quad-high module with multipoint microcode); 

• An H3254 (V.35 or integral modem) module test connector; 

• An H3255 (RS-423-A/232-C) module test connector; 

• A BC55H cable; and 

• An H325 and H3251 cable turnaround test connector. 

The DM VI 1-AB consists of: 

• An M8053-MA microcontroller/line unit (a quad-high module with multipoint microcode); 

• An H3254 (V.35 or integral modem) module test connector; 

• An H3255 (RS-423-A/232-C) module test connector; 

• A BC05Z-25 cable; and 

• An H3250 cable turnaround test connector. 

The DMV11-AC consists of: 

• An M8064-MA microcontroller/line unit (a quad-high module with multipoint microcode); 

• An H3254 (V.35 or integral modem) module test connector;- 

• A BC55F cable; and 

• H3257 and H3258 terminators. 

These three options provide coverage of four different types of interfaces (see Table 1-1). 

Features of the DMV 11 include: 

• Support of point-to-point and multipoint operation, 

• Support for remote or local, full-duplex, or half-duplex configurations, 

• Support for 12 tributaries and one control station in multipoint operation, 

• Switch and program selectable operating mode and tributary address, 

• Support for multiple addressed tributaries, 

• Down-line loading and remote load detect capabilities, 

• Go/No-Go diagnostic testing by the microcode, 

• Go/No-Go extensive error reporting, 

• Modem control. 



Table 1-1 DMV11 Options 



Option 


Interface 


Line Speed 

(DMV11 Limitations) 


DMV11-AA 


EIA RS-232-C 


Up to 19.2K b/s 




EIA RS-423-A 


Up to 56K b/s 


DMV11-AB 


CCITT V.35 


Up to 56K b/s 


DMV11-AC 


Integral modem 


56K b/s only 



1.4 STANDARD APPLICATIONS 

The DM VI 1 can be used with the integral modem as well as with EIA and CCITT applications. These 
applications can be configured as either point-to-point or multipoint networks. Figure 1-1 shows a typi- 
cal point-to-point application and Figure 1-2 shows a typical multipoint application. For local operations 
through integral modems, stations are interconnected by twinax or triaxial cables. The integral modem 
can support up to 12 drops in both half- and full-duplex modes. For remote operations, stations are 
connected through external modems that use common carrier facilities. For specific information on in- 
stallation of either of the basic DMV11 units and associated options, refer to Chapter 2. 

For multipoint applications, the tributary address for each DMV11 in the network is either switch or 
program assigned. In the case of switch-assigned tributary addresses, specific switches on each DM VI 1 
define the numerical value of the address to which that DMV11 responds. The advantage of a switch- 
assigned tributary address is that it provides data transfer security since the address cannot be changed 
by software. 

A major advantage of DM VI 1 multipoint networks is the ability of the main CPU at the control station 
to down-line load programs to the CPU at each tributary and start those programs without manual in- 
tervention. As a result, DMVll-based multipoint networks are particularly suited for installation at 
remote and generally inaccessible locations. For example, DM VI Is may be used in satellites, in hard to 
reach locations such as weather stations at sea, and in hazardous environments. 

1.5 DMV11 SYSTEM OPERATION 

Operation of the DMV11 communications line controller is initiated and directed by a user program 
residing in the main memory. The user program consists of an application program and a device driver 
that serves as an interface between the DMV11 and the CPU. 

Communication between the user program and the DMV11 is accomplished over the LSI- 11 bus 
through four control and status registers (CSRs). These four 1 6-bit registers serve as a bidirectional 
port to pass user-program commands to the DM VI 1, and DM VI 1 responses to those commands back to 
the user program. Each of these registers are word and byte addressable by both the user program and 
the DMV 1 1 microcode. 

NOTE 

Normally only four CSRs are available to the user 
program. However, in 22-bit address mode, eight 
CSRs are available although only one additional 16- 
bit register is used. 

In this group of four CSRs, the first two have a fixed format and in general serve as a handshake con- 
trol for user-program commands and DMV 11 responses. The next two CSRs form a port for the ex- 
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change of command and responses between the user program and the DMV 1 1 . Other control fields 
provide for initialization, interrupt enabling, reading and execution of maintenance instructions, data 
transfer setup, and tributary addressing. 

A user program issues a command to the DMV1 1 by first requesting the use of the data port. When the 
DMV1 1 grants permission to use the data port, the user program passes the command to the DMV1 1 in 
the CSRs. The DMV 11 interprets the command and performs the specified actions. If a response is 
required, the DMV1 1 stores the appropriate response in the CSRs and then informs the user program 
that a response is present. 

Message data received or to be transmitted by the DMV11 is written into or read from preassigned 
buffers in main CPU memory. These buffers are accessed by the DMV 11 through' nonprocessor 
requests (NPRs) to the associated bus address. 
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Figure 1-1 DMVlls Used in Point-to-Point Applications 



1.6 COMMAND/RESPONSE STRUCTURES 

Since the DMV1 1 is basically an input/output device, it follows that the command/response set for this 
device be categorized as input commands and output responses. Input commands are commands issued 
by the user program to the DMV1 1. Output responses are typically responses to those commands, and 
are issued by the DMV1 1 to the user program. 

Some responses are unsolicited, and are used to inform the user program of protocol events and line 
errors. 

1.6.1 Input Commands 

There are four types of input commands. They are listed below in the usual order of issuance. 

1. Microprocessor control/maintenance, 

2. Mode definition, 

3. Control, 

4. Buffer address/character count. 
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Figure 1-2 DMVlls Used in Multipoint Applications 



1.6.2 Output Responses 

Output responses serve to inform the user program of normal or abnormal conditions concerning the 
data transfer operation. There are three types of output responses: 

1. Control response, 

2. Information response, 

3. Buffer disposition response. 

Figure 1-3 is a general summary of the functions performed by the DMV11 command/response struc- 
ture. These commands and responses are discussed in detail in Chapter 3. 

1.7 PROTOCOL SUPPORT 

In DM VI 1 point-to-point and multipoint networks, all message transfers between nodes are under con- 
trol of the Digital Data Communications Message Protocol (DDCMP). All aspects of DDCMP process- 
ing are handled by the DMV11 microcode. Message handling at the user-program level only involves 
setting up data buffers during transmit operations and accepting data from the DMV1 1 during receive 
operations. 

There are no file structure constraints on messages transmitted or received over DMV11 networks; 
however, the maximum data message length allowed is 16,383 bytes. Also, there are no restrictions as 
to the type of data transmitted or received under DDCMP since all data is transmitted and received in 
transparent form. 

There are basically three types of DDCMP messages: the data message, the control message, and the 
maintenance message. 

1.7.1 Data Messages 

DDCMP data messages consist of two parts: the message header and the message body. The header 
consists of eight bytes of control information necessary for successful transmission of the message. In- 
cluded in these eight bytes is the block-check count (BCC) for the header, the byte count of the mes- 
sage body, and the tributary address. The header also contains two control bits; one that indicates res- 
ynchronization after this message, and one that controls line turnaround. The message body consists of 
the message and a BCC for the message. Both BCC characters are used by the DMV11 to validate 
messages as they are received. 

The header is assembled by the DMV11 and transmitted with the message body to form the data mes- 
sage. The receiving DMV11 uses the header to verify the address and ensure that the message is re- 
ceived in the correct sequence. The header is also used to determine the number of bytes to transfer to 
the user program. The header is discarded when the message is successfully passed to the user program. 

1.7.2 Control Messages 

Control messages are used to manage message traffic. They are eight-byte DDCMP messages which 
are passed between control and tributary stations under sole control of the DMV11. Two examples of 
control messages are acknowledge (ACK) and negative acknowledge (NAK). ACKs indicate successful 
reception of messages while NAKs indicate unsuccessful reception. Control messages in multipoint also 
contain the address field to identify the tributary to which the message is sent or received from. 

1.7.3 Maintenance Messages 

Under DDCMP, a DMV11 has two data transfer modes: the DDCMP run state, and the DDCMP 
maintenance state. In the run state, a DMV11 receives and transmits data messages. In the mainte- 
nance state, a DMV11 receives and transmits only maintenance messages. A maintenance message is 
formatted much like a data message. It is formed by an eight-byte header followed by a variable length 
message body. The content of the body is determined by the user program. Maintenance messages may 
consist of: 1) operating or diagnostic programs transmitted by the control station for down-line loading 
into the CPU of a specified tributary, or 2) a portion of the contents of a tributary's CPU memory as 
requested by the control station. The request of this information is also handled by a maintenance mes- 
sage. 
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Figure 1-3 General Summary of DMV11 Command/Response Structure 
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1.8 GENERAL SPECIFICATIONS 

Environmental, electrical, and performance specifications for all DMV11 configurations are listed in 
Sections 1.8.1 through 1.8.3. 

1.8.1 Environmental Specifications 

The DM VI 1 is designed to operate in a class C environment as specified by DEC STD 102 (extended). 

- Operating Temperature 5°C (41 °F) to 50°C (122°F) 

- Relative Humidity 10% to 90% with a maximum wet bulb temperature of 

28°C (82°F) and a minimum dew point of 2°C (36°F). 

1.8.2 Electrical Specifications 

The DMV1 1 requires the following voltages from the LSI-1 1 bus for proper operation. 

Option Voltage 

DMV1 1-AA,AB + 5V@3.4A 

+ 12 V ©0.380 A 

DMV11-AC +5 V @ 3.35 A 

+ 12 V@ 0.260 A 

A — 1 2 V @ 250 mA required by the level conversion logic for both versions is generated off the + 12 V 
by a switching inverter. 

1.8.3 Performance Specifications 

Performance parameters are as follows: 

- Operating mode Full- or half-duplex 

- Data format Synchronous DDCMP 

- Data rates Up to 56K b/s 

- Tributaries supported Up to 1 2 

DMVlls may be connected to DMP1 ls/DMVl Is, DMRlls, DMClls, and any other synchronous 
controller running DDCMP protocol. 
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CHAPTER 2 
INSTALLATION 



2.1 INTRODUCTION 

This chapter provides all the information necessary for a successful installation and subsequent check- 
out of the DM VI 1. Included are instructions for unpacking and inspection, preinstallation, installation, 
and verification of operation. 



2.2 UNPACKING AND INSPECTION 

The DMV11 is packaged according to commercial packing practices. When unpacking, remove all 
packing material and check the equipment against the packing list (Table 2-1 contains a list of supplied 
items for each configuration). Inspect all parts and carefully inspect the module for cracks, loose com- 
ponents, and separations in the etched paths. Report damages or shortages to the shipper and notify the 
DIGITAL representative. 



2.3 INSTALLATION CONSIDERATIONS 

Installation of the DMV11 microcontroller/line unit subsystem should be done in three phases: 

• Phase I - Preinstallation considerations 

Verify system requirements, system placement, and configuration requirements. 
Network topology chart 

For multipoint networks it is absolutely necessary to know the configuration of the DM VI 1 
(that is; control, tributary, HDX, FDX, and so on) locations of tributaries (w/address), and 
where in network they are connected (control, Trib 187, Trib 98, Trib 208) or else trouble- 
shooting will be extremely difficult. 

• Phase II - Microcontroller/line unit installation 

Configure, install, and verify the microcontroller/line unit module via the appropriate diag- 
nostics. 

• Phase III - DMV11 system testing 

Verify the DMV11 microprocessor subsystem operation with the functional diagnostics and 
system exerciser programs. 
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Table 2-1 DMV11 Option Packing List 



Option 


Parts List 


Description 


DM V 1 1-AA 




Ko-zJz-L,/Ko-4zi-A interlace containing: 




MoUjj-MA 

BC55H 

H3254, H3255 

H3251,H325 

EK-DMVll-UG 

MP-00942 

ZJ328-RB 


Basic remote DM VI 1 unit 

EIA RS-232-C/RS-423-A panel assembly 

Module test connectors 

Cable turnaround test connector 

DMV1 1 User's Guide 

Field Maintenance Print Set 

LIB kit 


T\\/f V 11 AD 

DM V 1 1-ArJ 




CCITT V.35 interface containing: 




iviou j j-ivi/\ 

BC05Z-25 

H3250 

H3254, H3255 
EK-DMVll-UG 
MP-00942 
ZJ328-RB 


Ddsic remote divi v i i unn 

CCITT V.35 cable 

Cable turnaround test connector 

Module test connectors 

DMV11 User's Guide 

Field Maintenance Print Set 

LIB kit 


DM V 1 1-AL 




Integral modem interface containing: 




M8064-MA 

BC55F-10 

H3254 

H3257/H3258 
EK-DMVll-UG 
MP-00942 
ZJ328-RB 


Basic local DMV11 unit 
Integral modem cable 
Module test connector - 
BC55A terminators 
DMVll User's Guide 
Field Maintenance Print Set 
LIB kit 



2.4 PREINSTALLATION CONSIDERATIONS 

Table 2-1 and the following should be considered prior to ordering a DM VI 1 communications interface 
to ensure that the system can accept the DM VI 1 and that it can be installed correctly. The steps should 
also be verified at installation time. 

It is strongly recommended that a topology diagram be drawn at installation time and maintained 
throughout the life of the installation. Figure 2-1 shows a local network topology and Figure 2-2 shows a 
remote network topology. The topology diagram should provide the following information. 

Cable routing - Show the actual physical location of the cable trough and in- 

dicate any equipment which might cause interference such as 
an X-ray room. 

Machine type - Indicate whether the CPU is a PDP-1 1/23, PDP-1 1/70, PDP- 

11/34, VAX-1 1/780, and so forth. (The network could consist 
of a mixture of DMP1 Is and DM VI Is). 

Type of station - Indicate if the station is a control or tributary station. 

Physical address - DDCMP address can range from 1-255. 
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Location - 



Node name - 

Operating system and 
version - 



DECnet version - 
Transmit and receive 



Indicate by room number or other appropriate means, the ac- 
tual physical location of the equipment. 

The name given to the tributary if applicable. 

The name of the software operating system such as RSX-1 1M 
V3.2. 

DECnet software version such as DECnet- 1 1M V3.0. 

Show transmit and receive lines. Depict end nodes and show 
termination. If a patch panel is used, indicate the line numbers 
between patch panels. 



NOTE 

The use of patch panels and numbering of the lines is 
recommended. 



RX 



TX 



DELTA 
1 1/70 
DMP1 1 
TRIB 3 
RSTS XX. X 
DE - XX.X 



ROOM 515 



ELEVATOR SHAFT 



SUSPENDED CEILING 



RX 



TX 



BETA 
1 1/34 
DMP 1 1 
TRIB 1 
RSX11 M 
DM ■ XX. X 



ROOM 412 



RX 



TX 



GAMA 
1 1/23 
DMV 1 1 
TRIB 2 
RSX 1 1 M 
DM ■ XX. X 



ROOM 430 



RX 



TX 



ALPHA 
VAX 1 1/780 
DMP 1 1 
CONTROL 
VMS XX.X 
DV - XX. X 



ROOM 1 1 1 



Figure 2-1 Local Network Topology 
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*NOTE 1 

PATCH PANELS ARE 
RECOMMENDED BUT MAY 
NOT ALWAYS BE USED IF THEY 
ARE USED, THEIR PHYSICAL 
LOCATION SHOULD BE 
INDICATED. 



♦NOTE 2 

MODEM - 208A 

CONTROL STATION OPTIONS 

SEE TABLE 2-2 



*NOTE 3 

MODEM - 208A 
TRIBUTARY OPTIONS 
SEE TABLE 2-3 



MERRIMACK 
MK1-1/K37 
VAX 11/780 
VAX VMS XX.X 
DV-XX.X 
♦NOTE 1 
♦NOTE 3 



CONTROL 



4800 



4800 



MARLBORO 
MR 




11/23 




RSX-1 1 M 




V.3.2 
DM XX.X 

♦note 1 

♦NOTE 2 










TRIB4 



NASHUA 
EXCHANGE 



4800 



NASHUA 
NU 

11/60 
RSTS XX.X 
DE-XX.X 
♦NOTE 1 
♦NOTE 3 

TRIB 1 



MAYNARD 
EXCHANGE 



MARLBORO 
EXCHANGE 



4800 



LOWELL 
EXCHANGE 



TEWKSBURY 
TW 



VAX 11/750 
VAX VMS XX.X 
DV-XX.X 

♦NOTE 1 

♦NOTE 3 

TRIB 2 



4800 



- MAYNARD 
| | PK3 

11/23 
RSX-1 1 M 
V.3.2 
♦NOTE 1 

TRIB 3 



Figure 2-2 Remote Network Topology 
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Table 2-2 Typical Host Options of a Bell 208A Data Set (4800 b/s) 
Full-Duplex Operation 



Data Set Options 


DEC Recommended Settings 


Transmitter timing 


Data set (internal) 




v_onunuous 


Request-to-send operation in 
continuous carrier mode 


Continuous (CB constantly ON) 


One second holdover at 
receiver on line dronnnts 


Not provided 


New sync-option to squelch 
receiver clock 


Not used - NS is strapped OFF 
within the data set 


Data set ready lead option 
for analog loopback testing 
by data terminal 


CC is ON when the AL button (only) 
is depressed 


Grounding option 


AB connected to AA 


Table 2-3 Typical Tributary Options of a Bell 208A Data Set (4800 b/s) 
Full-Duplex Operation 


Data Set Options 


DEC Recommended Settings 


Transmitter timing 


Data set (internal) 


Carrier control 


Switched (48.5 ms CA-CB delay) 


Request-to-send operation in 
continuous carrier mode 


Continuous (CB constantly ON) N/A 
Switched (8 ms ±.5 CA-CB delay) 
N/A 


One second holdover at 
receiver on line dropouts 


Not provided 


New sync-option to squelch 
receiver clock 


Not used - NS is strapped OFF 
within the data set 


Data set ready lead option 
for analog loopback testing 
by data terminal 


CC is ON when the AL button (only) 
is depressed 


Grounding option 


AB connected to AA 



2-5 



2.4.1 Device Placement 

The DM VI 1 can be installed in any LSI-1 1 bus-compatible backplane such as H9276. On systems that 
contain many high-speed direct memory access (DMA) devices, there is a probability of adverse bus 
latency. To help prevent against this occurrence, the DMV11 should be placed physically close to the 
processor. As a result, this gives the DMV11 a high DMA priority. 



2.4.2 System Requirements 

• LSI-1 1 bus loading 

The M8053-MA or M8064-MA present two ac loads and one dc load to the LSI-1 1 bus. 

• Power requirements 

Check the power supply before and after installing the microcontroller/line unit to ensure 
against overloading. Power requirements are listed in Table 2-4. 

• Interrupt priority 

The interrupt priority is preset to level four. 

• Device address assignment 

The DMV11 address resides in the floating address space of the LSI-1 1 bus addresses. The 
ranking assignment of the DMV11 for bus address is 24. 

The selection of the device address is accomplished by switch packs on the micro- 
controller/line unit module. Refer to Figures 2-3 and 2-4. 

• Device vector address assignment 

The DMV11 vectors reside in the floating vector space of the LSI-1 1 bus addresses. The 
ranking assignment of the DMV11 for vector assignments is 46. 

The selection of the vector address is accomplished by a switchpack on the micro- 
controller/line unit module. Refer to Figures 2-3 and 2-4. 



Table 2-4 DMV1 1 Voltage Chart 



Module 


Voltage Rating 


Maximum 
Voltage 


Minimum 
Voltage 


Backplane 
Pin 


M8053-MA 


+ 5 V@3.4A 


+ 5.25 


+ 5.0 , 


AA2 




+ 12 V@ 0.380 A 


+ 12.60 


+ 11.40 


AD2 


M8064-MA 


+ 5 V @ 3.35 A 


+ 5.25 


+ 5.0 


AA2 




+ 12 V@ 0.260 A 


+ 12.60 


+ 11.40 


AD2 
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Figure 2-3 M8053 Switch Locations 
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Figure 2-4 M8064 Switch Locations 
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2.5 INSTALLATION 

When installing the DMV11 in the LSI-11 bus-compatible backplane, LSI-11 configuring rules must 
be followed. 



Proceed with the installation as follows by performing the following on the slot that will contain the 
DMV11. 



1. Verify that the backplane voltages are within the tolerances specified in Table 2-4. 

2. Turn system power OFF and perform resistance checks on the backplane voltage sources to 
ground. This ensures that no short circuits exist. Refer to Table 2-4 for backplane pin assign- 
ments. 



3. Configure the correct device address using switchpack settings from Table 2-5. 

4. Configure the correct vector address using switchpack settings from Table 2-6. 

5. Verify that the switch selectable features of the DM VI 1 are configured for the station being 
installed. See Figure 2-5. 

6. Insert the appropriate module test connector into the correct microcontroller/line unit con- 
nector as specified in Table 2-7. Be sure to insert the" test connector with "SIDE 1" (etched 
on the test connector) visible from the component side of the module. Refer to Figure 2-6 and 
2-7. 



Schematics and outline drawings of each test connector used with the DM VI 1 are provided 
in Figure 2-8. 



7. Turn system power ON. 



8. Load and execute the DMV11 static diagnostics. Five error-free passes of each part is the 
minimum for successful operation. 



(C)VDMA** - DM VI 1 static logic test part 1 
(C)VDMB** _ DMV11 static logic test part 2 
(C)VDMC** - DMV1 1 static logic test part 3 
(C)VDMD** - DMV1 1 static logic test part 4 
(C)VDME** - DMV1 1 static logic test part 5 

Remove the module turnaround test connector and connect the appropriate cable (see Table 
2-7 and Figure 2-9) to the proper Berg connector for the DMV11 option selected. Refer to 
Table 2-7 for detailed information on cable requirements and to Figures 2-10 through 2-14 
for system cabling configurations. 



NOTE 

When installing panel cables BC55F or BC55H, it is 
important that the panel be properly mounted to the 
rear-mounting bulkhead to ensure adequate ground- 
ing. 
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When connecting the BC55H connector panel, verify that the appropriate modem jumpers on 
the panel are properly configured for the option selected. Table 2-8 lists each of these options 
and required jumper configurations. 

Integral modem options require that a 75 ohms terminator be connected to each receive line 
(BC55F panel) at each end of a full-duplex and a half-duplex network. These terminators are 
available in both male (H3257) and female (H3258) types to accommodate different integral 
modem cabling. Selection of the appropriate terminator type is dependent upon which type 
of unused panel connector is available on the receive line at the BC55F panel. Refer to Fig- 
ure 2-10 for DM VI 1 remote cabling and to Figure 2-1 1 for DM VI 1 to DM VI 1 local cabling. 

10. Insert the appropriate cable turnaround test connector in the end of the cable. Refer to Table 
2-7 for the specific test connector. Load and execute the static diagnostics specified in Step 8 
using the external maintenance mode selected to verify the module and cable. Upon obtain- 
ing a minimum of five error-free passes, proceed to the DM VI 1 system test procedures, Sec- 
tion 2.6. Figure 2-8 illustrates the various test connectors used in the DMV11. 

2.6 DMV11 SYSTEM TESTING 

The final step in the installation of a DM VI 1 subsystem is to exercise the DM VI 1 as: 1) a unit on the 
LSI- 11 bus; and 2) a link in a communications network. 

2.6.1 Functional Diagnostic Testing 

Ensure that the specific cable turnaround test connector for the selected DMV1 1 option is still installed 
at the end of the cable. Load and execute the DMV11 functional diagnostics with the external mode 
selected. Upon obtaining a minimum of five error-free end passes, proceed to Section 2.6.2. 

2.6.2 DEC/X11 System Exerciser 

The DEC/X11 system exerciser for the DMV11 can be run in two different operating modes, internal 
and external. The internal mode selects faster LSI-1 1 bus activity. The external mode requires that the 
specific modem test connector be installed at the end of the cable. This is the preferred mode of oper- 
ation. There are two DEC/X11 modules for the DMV11; DMD* and DME*. 

2.6.3 Final Cable Connections 

The final step in the installation process is to return the DM VI 1 to its normal cable connections, either 
to the appropriate modem or to the distribution panel. The DM VI 1 system cabling diagrams in Figures 
2-10 through 2-14 have been included to help show overall cabling for the various DM VI 1-XX options. 
References to specified locations of the various test connectors during diagnostic testing are also includ- 
ed. After the cables are connected to the appropriate modem or distribution panel, it is suggested that 
the data communications link test program (DCLT) be exercised. 

2.6.4 DMV11 Link Testing 

The DMV11 can be exercised over a communications link by the data communications link test 
(DCLT). It is suggested that DCLT be configured to run first on a cable test connector and then on a 
modem with the modem analog loopback test feature selected (if the modem includes this feature). 
Next, the overall communications link should be exercised with the remote computer system that con- 
tains a DMV11. 
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Table 2-5 Device Address Selection 



MSB 



LSB 



15 



14 



13 



12 I 11 



10 



M8053 E53 M8064 E 58 



1 — T 



M8053 
E54 

M8064 
E59 



SWITCH 
NUMBER 



S8 



S7 



S6 



S5 



S4 



S3 



S2 



S1 



S2 



S1 



DEVICE 
ADDRESS 



ON 
ON 



ON 



ON 



ON 



ON 
ON 
ON 
ON 



ON 
ON 



ON 
ON 



ON 



ON 



ON 



ON 



ON 
ON 



ON 



ON 



760020 
760040 
760060 
760100 
760200 
760300 
760400 
760500 
760600 
760700 
761000 
762000 
763000 
764000 



NOTE: SWITCH ON RESPONDS TO LOGICAL ONE ON THE BUS 
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Table 2-6 Vector Address Selection 



MSB LSB 



15 


14 


13 


12 


11 


10 


9 


8 


7 


e 1 5 


4 


3 


2 


1 


























«* 


M8053 E54 






1/0 









M8064 E59 



I 



I 



SWITCH 
NUMBER 


S8 


S7 


S6 


S5 


S4 


S3 


VECTOR 
ADDRESS 






ON 


ON 








300 






ON 


ON 






ON 


310 






ON 


ON 




ON 




320 






ON 


ON 




ON 


ON 


330 






ON 


ON 








340 






ON 


ON 


ON 




ON 


350 






ON 


ON 


ON 


ON 




360 






ON 


ON 


ON 


ON 


ON 


370 




ON 












400 




ON 




ON 








500 




ON 


ON 










600 




ON 


ON 


ON 








700 



















NOTE: SWITCH ON PRODUCES LOGICAL ONE ON BUS 
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8 7 6 5 4 3 2 1 



DDCMP ADDRESS REGISTER 
TRIBUTARY/PASSWORD 



E 119 (M8064) 
E 113 (M8053) 



ZERO = "ON' 



MODE WHEN SWITCH 
ONE IS SET 



L 



7 
REMOTE 
LOAD 
DETECT 
ENABLE 



E 107 (M8064) 
E 101 (M8053) 




AUTO 
ANSWER 



POWER 
ON 
BOOT 
ENABLE 



UNIT 

NUMBER 

FOR 

BOOTING 



ZERO = "ON' 



MODE 
ENABLE 



8 


7 


6 


SWITCH SETTING FOR THE MODE OF OPERATION. 


ON 


ON 


ON 


HDX PT TO PT DMC COMPATIBLE 


ON 


ON 


OFF 


FDX PT TO PT DMC COMPATIBLE 


ON 


OFF 


ON 


HDX POINT TO POINT 


ON 


OFF 


OFF 


FDX POINT TO POINT 


OFF 


ON 


ON 


HDX CONTROL STATION 


OFF 


ON 


OFF 


FDX CONTROL STATION 


OFF 


OFF 


ON 


HDX TRIBUTARY STATION 


OFF 


OFF 


OFF 


FDX TRIBUTARY STATION 



10 



'ON" =V.35 
'OFF" = EIA 
M8053 



HIGH 
SPEED 



E 107(M8064) 
E 101 (M8053) 
OFF - "LOGIC ONE' 



HIGH SPEED SWITCH 
MUST BE SET 
FOR INTEGRAL 
MODEM OR WHEN 
RUNNING ABOVE 19.2KB 

* UNUSED 
ON 

M8064 
ZERO = "ON" 



MK-2493 



Figure 2-5 DMV11 Switch Selectable Features 
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Table 2-7 Cable Description 



Interface 


Cable 


Module 
Connector 


Test 

Connector 


Description 


RS-232-C 


BC55H 
Refer to 
Figure 2-9 
View A 


J2 

(M8053) 


H325 


A cable with a 40-pin 
Berg connector at one 
end. The other end 
has a panel that in- 
cludes two different 
cinch connectors, Jl 
and 52. Connector J2 
is used for RS-232-C 
to connect to the 
modem with external 
cable BC05D-25. The 
panel is mounted to 
a rear-mounted bulk- 
head to ensure proper 
grounding and ease of 
access to external 
cable connections. 




BC05D-25 
Refer to 
Figure 2-9 
ViewB 




H325 


A 7.6 m (25 feet) 
external cable that 
connects to J2 of the 
BC55C panel and an 
RS-232-C modem. 


RS-423-A 


BC55H-03 
Refer to 
Figure 2-9 
View A 


J2 

(M8053) 


H3251 


Same cable as used 
for RS-232-C except 
that panel connector 
Jl is used with ex- 
ternal cable BC55D-33 
for connection to the 
modem. The panel is 
mounted to a rear- 
mounted bulkhead to 
ensure proper ground- 
ing and ease of ac- 
cess for external 
cable connections. 




BC55D-33 
Refer to 
Figure 2-9 
ViewC 




H3251 


A 10.1m (33 feet) 
cable that connects 
toJl of the BC55H 
panel and an RS-449 
modem. 
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Table 2-7 Cable Description (Cont) 



Interface 


Cable 


Module 
Connector 


Test 

Connector 


Description 


V.35 


BC05Z-25 
Refer to 
Figure 2-9 
View D 


Jl 

(M8053) 


H3250 


A 7.6 m (25 feet) 
modem cable with a 
40-pin Berg connector 
at one end that con- 
nects to J 1 of the 
M8053. A 34-pin Data- 
Phone DIGITAL Service 
(DDS) connector is 
installed at the 
other end and con- 
nects to the modem. 


Integral 
Modem 


BC55F 
Refer to 
Figure 2-9 
View F 


Jl 

(M8064) 


Panel 
switch to 
HDX posi- 
tion 


A 0.9 m (3 feet) 
cable with a 40-pin 
Berg connector at one 
end that plugs into 
Jl of the M8064. The 
panel assembly is in- 
stalled at the rear- 
mounted bulkhead for 
ease of external con- 
nections and to en- 
sure proper ground- 
ing. ; 

Appropriate termina- 
tor connectors H3257 
or H3258 must be 
used. See Figures 2-9 
and View F. 


Integral 
Modem 


BC55N-98 
Refer to 
Figure 2-9 
View E 


Local link 
BC55F panel 


None 


A 29.9 m (98 feet) 
external twinax cable 
used to interconnect 
aDMPll or a DMR11 to 
a DM VI 1 system for a 
selected data rate of 
56K b/s. 




BC55M-98 
Refer to 
Figure 2-9 
View E 


None 


None 


A 29.9 m (98 feet) 
external triaxial 
cable used for the 
same purpose as the 
BC55N, but for data 
rates above 56K b/s. 
The DM VI 1-AC supports 
data rates of 56K 
b/s. 
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CONNECT CABLE BC05Z FOR V.35 INTERFACE 
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Figure 2-6 Test Connector Insertion for the M8053 
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Figure 2-7 Test Connector Insertion for the M8064 
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Figure 2-8 DM VI 1 Test Connectors (Sheet 1 of 4) 
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Figure 2-8 DM VI 1 Test Connectors (Sheet 2 of 4) 
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Figure 2-8 DM VI 1 Test Connectors (Sheet 3 of 4) 
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Figure 2-8 DMV1 1 Test Connectors (Sheet 4 of 4) 
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Figure 2-9 DMV1 1 Cable Drawings (Sheet 1 of 3) 
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Figure 2-9 DM VI 1 Cable Drawings (Sheet 2 of 3) 
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Figure 2-9 DM VI 1 Cable Drawings (Sheet 3 of 3) 
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Figure 2-10 DMV11 Remote System Cabling Diagram 
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Figure 2-1 1 DMV1 1 to DM VI 1 Integral (Local) Modem Cabling Diagram (Point-to-Point) 



2-26 



HDX NETWORK 



TERMINATOR 
(H3257) 




TERMINATOR 
(H3258) 



BC55F 



BC55F 



BC55F 



BC55F 



CONTROL 
STATION 




TRIBUTARY 




TRIBUTARY 




TRIBUTARY 



Figure 2-12 Half-Duplex Multipoint Network (Control Station End Node) 
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Figure 2-13 Full-Duplex Multipoint Network (Control Station End Node) 
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Figure 2-14 Full-Duplex Multipoint Network (Control Station Inner Node) 
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Table 2-8 Modem Option Jumper Functions 
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CHAPTER 3 

COMMAND AND RESPONSE STRUCTURES 



3.1 INTRODUCTION 

This chapter defines DMV11 command and response formats in all necessary detail, and describes all 
programming sequences relevant to DM VI 1 operation in the network environment. The CSR command 
structure and format of input commands and output responses, as well as data port descriptions, are 
described in detail. Discussions include special programming techniques, user access to maintenance 
mode, and user interpretation of status/error reporting. 

3.2 COMMAND STRUCTURE 

The DMV11 command set is structured into two categories; input commands and output responses. 
Brief overviews of input commands and output responses, including command codes and the hand- 
shaking requirements, are provided in this section. 

Transfer of control and status information between the main CPU resident user program and the 
DMV11 is accomplished through four 16-bit control and status registers (CSRs). Input commands are 
issued to the DM VI 1 by the user program, and output responses are issued to the user program by the 
DMV11. 

NOTE 

Normally only four CSRs are used, but in the 22-bit 
address mode, eight CSRs are available. 

3.2.1 Control and Status Registers 

Four 16-bit CSRs are used to transfer control and status information. These registers are both byte and 
word addressable. The eight bytes are assigned addresses in the floating address space in the I/O page 
as follows: 

16XXX0, 16XXX1, 16XXX2, 16XXX3, 16XXX4, 16XXX5, 16XXX6, and 16XXX7. 

For discussion, these byte addresses are designated byte select through 7 (BSELO through BSEL7). 
BSEL10 and BSEL1 1 are only used in 22-bit address mode. BSEL12 through BSEL17 are not used by 
the user/DMVll-command structure and are not referred to in this document. 

The four word addresses are the even numbered locations and are designated select 0, 2, 4, and 6 
(SELO, SEL2, SEL4, and SEL6). The CSR addresses are assigned to the floating address space. The 
floating address ranking for the DMV11 is 24 (See Appendix B). The relationship between the sym- 
bolic byte and word addresses for DMV11 CSRs, and the actual CSR layout, is shown in Figure 3-1. 
Figure 3-2 illustrates the fields in CSR bytes BSELO, BSEL2, and BSEL3 that comprise the fixed 
format portion of both user-program commands and DM VI 1 responses. This fixed format portion serv- 
es to identify the command/response type, address of the tributary that the command/response applies 
to, and coordinate ownership of the CSRs between the DMV11 and the user program. Detailed bit 
descriptions of SELO and BSEL2 are provided in Tables 3-1 and 3-2 respectively. 

The four bytes comprising SEL4 and SEL6 contain the fields pertinent to each user-program command 
and DM VI 1 response. Detailed descriptions of the SEL4 and SEL6 fields are presented in Sections 3.3 
through 3.4. 
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Figure 3-1 DMV1 1 CSRs Byte and Word 
Symbolic Addresses 
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Figure 3-2 Fixed and Variable Formats for Commands and Responses 



Table 3-1 SELO Bit Functions 



Bits 


Name 


Description 


BSELO 









Interrupt 
Enable In (IEI) 


When set, this bit enables the DM VI 1, upon asserting RDI (bit 4 
of BSEL2), to generate an interrupt to vector address XXO. 


1-3 


Reserved 




4 


Interrupt 
Enable Out 
(IEO) 


When set, this bit enables the DM VI 1, upon asserting RDO (bit 
7 of BSEL2), to generate an interrupt to vector address XX4. 


5-6 


Reserved 
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Table 3-1 SELO Bit Functions (Cont) 



Bits 



Name 

Request In 
(RQI) 



BSEL1 



Maintenance 
Request 



Description 

This bit is set by the user program to request access to the data 
port. It is cleared by the user program when the data port is not 
required for further issuing of commands. The user program may 
leave RQI set if successive requests for the data port are pending. 



When set, along with master clear (bit 14 of SEL4), this bit 
causes the DMV11 to enter the maintenance register emulation 
section of the microcode. 



NOTE 

Detailed discussion of maintenance register emula- 
tion is presented in Section 4.8. 



9-10 
11 



12 
13 



Reserved 

Diagnostic 
Mode 



Reserved 

Invoke P/MOP 
Boot 



When set, this bit allows diagnostic programs to change the mode 
of operation of the DMV11 using the mode definition command 
to override the mode switches. 



Invoke primary MOP mode. When set to one, this bit causes the 
DMV11 at this multipoint station to request that the control sta- 
tion initiate the primary MOP (maintenance operation protocol) 
boot procedure. In point-to-point networks, a DMV1 1 having this 
bit set requests the other station to initiate the primary MOP 
boot procedure. 



NOTE 

The master clear bit (bit 14) must also be asserted 
to use invoke P/MOP. 



14 



15 



Master Clear 



Run 



When set, this bit initializes the DMV11. The clock is enabled 
and the RUN flip-flop is set. Master clear is self-clearing. 

This bit controls running of the microprocessor. It is set by bus 
initialization or master clear. When run is cleared the micro- 
processor halts. 
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Table 3-2 BSEL2 Bit Functions 



Bits 


Name 


Description 


0-2 


Control/Response 
Code 


These bits define the type of input command or output response as fol- 
lows. 






Bits 

2 1 


Description 









Buffer address/character count 
(RCV) command or buffer disposi- 
tion (RCV complete) response 






1 


Control command or control re- 
sponse 






1 


Mode definition command or 
information response 






1 1 


Buffer disposition (RCV unused) 
response 






1 


Buffer address/character count 
(XMIT) command or buffer dis- 
position (XMIT complete) re- 
sponse 






1 1 


Reserved 






1 1 


Buffer disposition (sent but not 
acknowledged) response 






1 1 1 


Buffer disposition (not sent) 
response 


3 


22-Bit Mode 


This bit when set indicates to the DM VI 1 that the buffer address is in 
the 22-bit format. 


4 


Ready In 
(RDI) 


RDI is the DMV11 response to RQI, indicating to the user program 
that it has control of the CSRs to issue a command. It is cleared by the 
user program when the data port contains the input command. Clearing 
RDI returns control back to the DMV11. 


5-6 


Reserved 






7 


Ready Out 
(RDO) 


RDO is asserted by the DMV1 1 to indicate that the data ports (SEL4 
and SEL6) contain an output response for the user program. The user 
program must clear RDO after it has read this information. Clearing 
RDO returns the CSRs to the DM VI 1 . 
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3.2.2 Input Commands Overview 

In general, input commands provide the means for the user program to assign, receive, or transmit buf- 
fers to the DMV11. Detailed field descriptions and formats of each input command are provided in 
Section 3.3 

There are four types of input commands that can be issued to the DMV11 for execution. 

• Microprocessor control/maintenance command; 

• Mode definition; 

• Control; 

• Buffer address/character count. 

With the exception of the microprocessor control/maintenance command, input commands require an 
identification code in the first three bits of BSEL2 (see Figure 3-2). These codes, which define each 
command and variations of specific commands within the command set, are defined in Table 3-2 and 
listed in Table 3-3. 

NOTE 

CSR addresses are expressed in octal. 



Table 3-3 Input Command Codes 



Input Command Type 


Binary Code(BSEL2) 




Bit 


Bit 


Bit 




2 


1 





Mode definition 





1 





Control 








1 


Buffer address/character count 
(receive) 











Buffer address/character count 
(transmit) 


1 









3.2.3 Output Responses Overview 

Output responses provide a means for the DM VI 1 to report various normal and abnormal (error) condi- 
tions concerning the data transfer operation. Three basic responses are provided: 

• Buffer disposition; 

• Control; 

• Information. 

The buffer disposition response is used to return both used and unused buffers to the user program. 

The control response is used to report error conditions concerning the microcontroller/line unit hard- 
ware, data link, physical link, or remote station. It also passes protocol information to the user. 

The information response provides information requested by a control command from the user pro- 
gram. 
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3.3 DM Vll INPUT COMMANDS 

This section provides detailed descriptions of each input command. Command formats and data port 
usages are illustrated and defined. User-program execution requirements, command variables, and ac- 
tion taken by the DMV1 1 in response to commands are discussed. 

3.3.1 Microprocessor Control/Maintenance Command 

This single byte command has two functions; to initialize and cause the DMV1 1 to start running, and to 
cause entry into the microcode maintenance loop when the maintenance request bit is set. At start-up 
time under normal operating conditions, this is the first command issued by the user program in order 
to initialize the DMV11. 

The format for the DMV1 1 initialization register (BSEL1) is shown in Figure 3-3. To set the master 
clear bit and thereby cause entry into the DM VI 1 running mode, the user program moves a byte with 
an octal value of 100 to BSEL1. As a result, all condition-sensitive logic in the DM VI 1 is reset for start- 
up, and the start-up diagnostic is executed. When the diagnostic completes satisfactorily, the run bit in 
BSEL1 is set to one. This indicates that the DMV11 is running and the microcode is executing. 

Figure 3-4 presents a flow chart describing how to initialize the DMV11. A timeout counter is set to 
avoid the possibility of the user program being caught in an endless loop in case the internal diagnostic 
does not complete successfully. 
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Figure 3-3 Microprocessor Control/Maintenance 
Command Format 



3.3.2 Mode Definition Command 

Functionally, the mode definition command is used to establish the hierarchy of a network and the 
characteristics of the communications line serving that network. As shown in Figure 3-5, the mode defi- 
nition command contains two fields; the command type code field in BSEL2, and the mode field in 
BSEL6. The mode field contains a code defining the function to be performed by the command. 

With the mode definition command, the user program can designate the DMV11 as a control station, a 
tributary in a multipoint network, or as a node in a point-to-point network. In addition, the character- 
istics (half-duplex or full-duplex) of the physical communications line connecting the network can be 
defined. 

The actual mode field codes and the functions implemented by each code are listed in Table 3-4. 

Under normal operating conditions, the mode definition command is issued by the user program at 
start-up time (after the internal microdiagnostics have executed successfully and the run bit is set). 
Network discipline requires that each DMV11 in a network issue a mode definition command that is 
appropriate to the network. For example, in a half-duplex multipoint network comprised solely of 
DMVlls: 

1. The user program at the control station issues a mode definition command with the mode 
field set at four. 

2. The user program at each tributary station issues a mode definition command with the mode 
field set to six. 
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Figure 3-4 Initialization of the DM VI 1 
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This network discipline also applies to DMVlls operating in point-to-point networks with other 
DMVlls, DMPlls, DMClls, and DMRlls. 

When tributary addresses are software assigned, the mode definition command must be used at the 
control and tributary stations to configure the network and assign line characteristics. 

The functions performed by the mode definition command can also be implemented by the mode selec- 
tion switches on the DMV11 module. The switches must be used to establish mode definition functions 
when tributary addresses are switch assigned. The switch setting for performing the mode definition 
functions corresponds to the BSEL6 codes listed in Table 3-4. 

Once the type of station is set, it can only be changed by a master clear or a physical change in the 
switches. If the type of station is switch assigned, a master clear has no affect. However, the switches 
are overridden when the diagnostic mode bit (bit 3 of BSEL1) is set and a mode definition command is 
issued. 
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Figure 3-5 Mode Definition Command Format 



Table 3-4 Mode Field Codes and Functions 



BSEL6 Bit 


Line 


Network 


DMC1 1-Line 


Positions 


Characteristics 


Configuration 


Compatibility? 


2 1 











Half-duplex 


Point-to-point 


Yes 


1 


Full-duplex 


Point-to-point 


Yes 


1 


Half-duplex 


Point-to-point 


No 


1 1 


Full-duplex 


Point-to-point 


No 


1 


Half-duplex 


Control station 


N/A 


1 1 


Full-duplex 


Control station 


N/A 


1 1 


Half-duplex 


Tributary station 


N/A 


1 1 1 


Full-duplex 


Tributary station 


N/A 
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3.3.3 Control Command 

This command is the primary means of controlling the operation of DM VI 1 -implemented networks. 
The format of the control command is illustrated in Figure 3-6. 

At start-up time, the user program at the DMV11 control station must issue one control command (es- 
tablish tributary) for each tributary address supported in the multipoint network. This must be done 
after issuing the microprocessor control and mode definition commands. This causes the microcode to 
create a tributary status slot (TSS) in the DMV11 data memory for each tributary in the network. 

Similarly, the user program at each tributary must issue a control command (establish tributary) for 
each tributary to be established at that station. This causes a TSS to be created at that station for each 
tributary it establishes. 

In point-to-point networks, a control command (establish tributary) must be issued at both stations. The 
tributary address field in this case must be a one. This results in the creation of a single TSS structure 
at each station. 



The DM VI 1 microcode at the control station and at all tributary stations uses these TSS structures to 
coordinate protocol operation over the network between the control/tributary pair. User programs, at 
the control station and at the established tributaries, access these structures to obtain operational infor- 
mation such as: 



• The number of messages transmitted and received; 

• The number of selection intervals and timeouts; 

• The number of reply timeouts; and 

• The number of various types of errors. 
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Figure 3-6 Control Command Format 
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At the start-up of tributary stations having multiple software assigned tributary addresses, the user pro- 
gram at each station issues as many control commands as there are established tributaries at that node. 
However, in networks where tributary addresses are switch assigned, only one control command speci- 
fying the switch assigned address is required as part of the start-up sequence. Any other nonzero tri- 
butary address in a control command is overridden by the switches. 

The control command is also used by the user program at the control station to specify a unique set of 
polling parameters for each tributary in the network. 

During normal operation, the control station microcode can determine the polling level of any tributary 
in the network and adjust the polling frequency of that tributary as necessary (see Section 5.2). 

The control command permits the user program to perform a number of control functions using the 
same command format. In general, each function implemented by this command requires issuing of a 
single appropriately formatted control command. SEL6 is used to define the various functions of the 
control command (see Figure 3-6). Table 3-5 provides a detailed description of each bit or field. 



Table 3-5 SEL6 Control Command Functions 



Bit 


Name 


Description 


0-4 


Request Key 


These five bits are encoded requests from the user program. When this field is 
used, bits 5 through 7 must be cleared. Request keys are encoded as shown in 
Table 3-6. 


5 


Read TSS/GSS 


A control command with this bit set, allows the user program to read two con- 
secutive locations (two bytes) of a tributary status slot (TSS) or global status 
slot (GSS) without modifying it. 

The TSS to be read is specified in BSEL3 and the location within the TSS is 
specified in bits 0-4 of BSEL6. Notice that bit 5 is also set to indicate a read 
GSS. To read a GSS location, BSEL3 is zero. 

When the DM VI 1 receives a control command to read a TSS or GSS location, 
it passes the requested information to the user program through an information 
response (see Section 3.4.3). However, the requested information is placed on 
an internal queue before it is passed to the user program. As a result, the infor- 
mation requested may change before the user gets it. This is particularly true 
for number of messages transmitted/received and selection intervals. 


6 


Read and 
Clear TSS/GSS 


A control command with this bit set, allows the user program to read and clear 
specific locations in a TSS or GSS. 

The TSS to be read is specified in BSEL3 and the location within the TSS is 
specified in bits 0-4 of BSEL6. Notice that a read and clear command bit 6 of 
BSEL6 is also set. This gives a base octal value of 100 to which the specific 
TSS address is added. To read and clear a GSS location, BSEL3 is zero. 

Only the error counter sections of the TSS (7-17 octal) and GSS (15-17 octal) 
can be accessed with a read and clear command. 
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Table 3-5 SEL6 Control Command Functions (Cont) 



Bit 


Name 


Description 






Accessing any other locations results in a procedural error. 






Valid octal values for BSEL6 for the read and clear function are listed below: 






Octal Value 

V/V I til T AlUV 


TSS Titration 






107 


Data messages transmitted 






110 


Data messages received 






111 


Selection intervals 






112 


Data errors outhonnd 






113 


Data errors inbound 






114 


Local buffer errors 






115 


Remote buffer errors 






116 


Selection timeouts 






117 


Local and remote reply timeouts 






Octal Value 


GSS Location 






115 


Remote station errors 






116 


Local station errors 






117 


Global header blockcheck and 








maintenance data blockcheck 








errors 








These errors are covered in 








detail Section 5.3. 






When the DM VI 1 receives a control command to read and clear a TSS or GSS 






location, it passes the requested information to the user program through an in- 






formation response, and then clears the location. 






As in the case of the read TSS/GSS, the information is placed on an internal 






queue and is subject to change before the user gets it. However, by reading and 






clearing, the user can keep a cumulative total. 


7 


Write TSS 


A control command with this bit set, enables the user program to write into spe- 






cific locations in an associated TSS or GSS. 






The TSS to be written into is specified in BSEL3 and the specific location with- 






in the TSS or GSS is 


specified in bits 0-4 of BSEL6. To write to a GSS loca- 






tion, BSEL3 is zero. 






Notice that bit 7 of BSEL6 is also set to indicate a write TSS. This gives a base 






octal value of 200 to which the specific TSS address is added. 
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Table 3-5 SEL6 Control Command Functions (Cont) 



Bit 


Name 


Description 






The data to be written is contained in BSEL4 and BSEL5. There are eight TSS 
and five GSS parameters that can be written: 






TSS PARAMETER 


BSEL6 






1. 


Transmit delay timer (XDT) 








2. 


Initial polling urgency (Q) and 
polling rate (R) for active 
state 


231 






3. 


Initial polling urgency (Q) and 

nollinp ratp fR^ for inactivp 

state 


232 






4. 


Initial polling urgency (Q) and 
polling rate (R) for unresponsive 
state 


233 






5. 


No data message count (non-inact) 
and unresponsive timeout count 
(TO-UNRESP) 


234 






6. 


Dead timeout count (TO-DEAD) 
and maximum message count (M MC) 


235 






7.' 
8. 


Selection interval timing 
counter 

Babbling tributary counter 
See Table 4-2 for details 


236 

Z.J 1 






GSS PARAMETER 


BSEL6 






1. 


Number of sync-characters to 
precede nonabutting messages 


233 






2. 


Preset value for streaming 
tributary time counter 


234 






3. 


Polling algorithm update 
interval (DELTA T) 


235 






4. 


Polling rate for dead tribu- 
taries (DEAD T) 


236 






5. 


Fixed polling delay (poll 
delay) 

See Table 4-3 for details 


237 






NOTE 

Some parameters are 8-bits in length. Thus, in those 
cases two parameters are indicated. All user ac- 
cesses are on two byte boundaries. 
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Table 3-5 SEL6 Control Command Functions (Cont) 



Bit 


Name 


Description 


8 


Enable 

Common 

Pool 


A control command with this bit set allows a specified tributary (BSEL3) to use 
the common receive buffer pool. Usage of the common pool is based on a com- 
mon pool quota. This quota is determined for the specified tributary by adding 
the octal value in BSEL4 to the current quota. If this results in a value equal to 
or greater than 377 octal, a procedural error results and the quota is reset to 
376. However, a tributary may be set up for unlimited use of the common pool 
by setting BSEL4 to 377. Each time a tributary uses a common pool buffer, the 
quota is decremented by one. When the quota reaches zero, the tributary is pre- 
vented from using the common pool. See Section 3.3.4 for more details on com- 
mon buffer pool. 

TVif* p/im mnn r\f*r\1 is pVippk f»H first Tf no Viiiffprc arp ov/iiilii V\1p nv tlif* nnr\ta ic 

1 11C dJllllllUlI UUvJl lo VUd'HCU 11151. 11 11U UU11C1S dlC avallaUlC Ul Lllw UUULa la 

zero, or the buffer is too small, the private receive buffers are checked. 


9 


Disable 
Common Pool 


A control command with this bit set, disables the use of the common receive 
buffer pool for the tributary specified in BSEL3. 

The quota previously established for this tributary is cleared to zero. 


lO- 
ll 


Reserved 




12 


Unlatch Poll- 
ing State 


A control command with this bit set, causes the polling state level of the tributa- 
ry addressed by BSEL3 to go to the active polling state. Control of the polling 
activity for the specified tributary is then returned to the polling algorithm. 


13 


Latch Poll- 
ing State 


A control command with this bit set, establishes the polling state of the tributa- 
ry addressed by BSEL3. The polling state is determined by bits and 1 of 
BSEL4. These bits are encoded as follow: 

Bitsl&O Polling State 

00 Active 

01 Inactive 

10 Unresponsible 

11 Dead 
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Table 3-6 Request Key Field Definitions (Control Command) 



Octal 
Code 


Name 


Description 


00 


No Request 


This code allows the issuing of a null control command for the purpose 
of returning control of the CSRs to the DMV1 1 . The no request code 
is used when RDI is set but there is no command to issue (see Section 
4.2.3). This is effectively an NOP command. 



Establish 
Tributary 



NOTE 

The enable/disable common pool and/or 
latch/unlatch polling state bits in BSEL7 can be 
used in conjunction with this request key. 



This control function initiates the creation of the tributary status slot 
(TSS) data structure. This must be accomplished before any com- 
mand is issued that uses a tributary address. 



The user program at the control station must issue one establish tri- 
butary control command for each tributary supported in the network. 
The tributary address is designated in BSEL3. 



NOTE 

In a point-to-point network, this control command, 
with a tributary address of one in BSEL3, should be 
issued at each station to establish the required TSS. 



The DMV1 1 has 12 available TSS blocks. Each block has 64 - 8-bit 
locations for storing status and other information necessary for main- 
taining communications over the data link. 

As a result of establishing one or, more tributary addresses, the 
DMV11 creates a global status slot (GSS). This GSS is part of the 
overall status structure at each station. 



NOTE 

This control command function can also be used 
during normal operation of a multipoint network to 
reestablish previously deleted tributaries. In such 
cases, the tributary address must be reestablished at 
both the control station and the pertinent tributary 
station. 



NOTE 

The enable/disable common pool and /or the 
latch/unlatch polling state bits in BSEL7 can be 
combined with this control function in a single con- 
trol command. 
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Table 3-6 Request Key Field Definitions (Control Command) (Cont) 



Octal 
Code 




Description 



02 



Delete 
Tributary 



03 



Request Start-up 
State 



This control function removes a specified tributary from operational 
status by eliminating its associated TSS. Prior to issuing this com- 
mand, the user program must first halt the tributary being deleted. 
[See request key 05 (request halt state)]. The TSS can only be rees- 
tablished by using an establish tributary function. Only 12 addresses 
may be established at any one time. 



This control function initializes the designated TSS and initiates the 
DDCMP start-up sequence for that tributary. BSEL3 specifies the tri- 
butary address. Request start-up state must only be issued to tribu- 
taries that "are in the halt state. 



When the start-up sequence is completed, the DMV11 notifies the 
user program by issuing a control response. When this response (run 
state) is received by the user programs at the tributary and control 
station, message traffic can begin between these two stations (see 
Table 3-7). 



NOTE 

The enable/disable common pool and/or the 
latch/unlatch polling state bits in BSEL7 can be 
combined with this control function in a single con- 
trol command. 



04 



Request Maint 
State 



This control function places the tributary designated by BSEL3 into 
the DDCMP maintenance state. 



A tributary placed in the maintenance state can only transmit and re- 
ceive maintenance messages. Both the control station and tributary 
must be in the maintenance state in order for maintenance message 
traffic to occur. 



The maintenance state must only be issued to tributaries that are in 
the halt state. 



NOTE 

The enable/disable common pool and/or the 
latch/unlatch polling state bits in BSEL7 can be 
combined with this control function in a single con- 
trol command. 
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Table 3-6 Request Key Field Definitions (Control Command) (Cont) 



Octal 
Code 


Name 


Description 


05 

20 
21 


Request Halt 
State 

Th< 
reti 
plis 
BS1 

Tri 
this 
a pi 
7). 

Read Modem 
Control 

Write Modem 
Control 


This control function places the tributary designated by BSEL3 into 
the DDCMP halt state. All outstanding buffers are returned. 

When a tributary is halted at the control station, the tributary is no 
longer polled. When a tributary is halted by its own user program, it 
no longer responds to polling. 

The TSS for the halted tributary remains unchanged at both the con- 
trol and tributary stations. The halted tributary can be restarted by 
issuing a request start-up state control command. 

NOTE 

5 halt state may also be used on a global basis to 
lrn all common pool buffers. This is accom- 
hed by using a tributary address of zero in 
£L3 when issuing the request halt state. 

>utaries must not be using the common pool when 
function is issued. If the common pool is in use, 
rocedural error of 136 is generated (see Table 3- 

This control function permits the user program to write the contents of 
BSEL4 into the DMV11 modem register. (See Appendix C). 

This control function causes the DMV11 to read the modem register 
and pass this information to the user program through SEL4 by way 
of an information response. (See Appendix C.) 



NOTE 

Request key codes 6-17 and 22-37 are reserved. 



3.3.4 Buffer Address/Character Count (BA/CC) Command 

This command provides the user programs at both the control station and tributaries with the means to 
assign, transmit, and receive buffers. 

The format for this command is shown in Figure 3-7. Note that the command has two forms to facilitate 
separate management of transmit and receive buffers. These two forms are distinguished by the type 
code in BSEL2. A type code of zero is used to allocate receive buffers and a type code of four is used to 
allocate transmit buffers. 

The tributary address is specified by BSEL3 and the buffer address is contained in SEL4 and bits 14 
and 15 of SEL6. The remaining 14 bits of SEL6 contain the character count in positive notation. A 
character count of zero is illegal. 
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In addition to allocating receive and transmit buffers, the buffer address/character count command is 
used to allocate common receive buffers by specifying a tributary address of zero in BSEL3. These 
buffers can only be used by tributaries authorized to do so by the enable common pool bit of a control 
command. 

When the user program has a message to transmit, it informs the DM VI 1 of the size and address of the 
message buffer. This is done by the buffer address/character count command on a one buffer per com- 
mand basis. A tributary address of zero when assigning transmit buffers results in a procedural error. 

When the user program is receiving messages, it assigns receive buffers on a one buffer per command 
basis using the buffer address/character count command. These buffers may be in the common pool of 
buffers or be private buffers. Each BA/CC command used to assign a buffer to be the common pool 
must contain a zero in BSEL3. Although this command assigns buffers to a common pool, actual alloca- 
tion is performed through the control command by enabling access to the common pool on a per tributa- 
ry basis. 



BSEL3 



BSEL5 



BSEL7 
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5 4 3 2 1 
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"1 
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IEI 
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CMD TY 
.CODE 5 
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BUFFER ADDRESS 
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BU 

i 


FFER A 
LOW 


kDDREi 
BYTE 


5S 

■ i 


B/A 
17 


B/A 
16 


CHARACTER COUNT 

HIGH SIX BITS 
i i i i i 


CHARACTER COUNT 
, ■ i LOW BYTE ( , , 


15 


14 


13 12 11 10 9 


8 
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RDO 
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MODE 
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CODE* 
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BUFFER ADDRESS 

HIGH BYTE 
1 1 1 1 1 






BUFFER ADDRESS 
LOW BYTE 








UNUSED 
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BUS ADDRESS BITS 16-21 
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■4 




UNUSED *► 
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UNI 


SED 
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15 14 
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BUFFER ADDRESS/CHARACTER COUNT COMMAND - RECEIVE = 000 
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Figure 3-7 Buffer Address/Character Count Command Format 
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In multipoint networks, user programs at both the control and tributary stations can handle allocation 
of receive buffers in two ways: 

1. The first method involves the allocation of receive buffers from a common pool of buffers. 
With the common buffer pool enabled, receive buffers are assigned to the pool through the 
buffer address/character count command on the basis of one buffer for each command is- 
sued. Each buffer address/character count command used to assign a buffer to the common 
pool must contain a zero in BSEL3. Although this command assigns buffers to a common 
pool, actual allocation to a tributary is done through the control command by enabling access 
to the pool and assigning quotas (see Table 3-5). 

2. In the second method, the user program can directly allocate private receive buffers based on 
anticipated message traffic using one buffer address/character count command for each pri- 
vate buffer allocated. In this context, a private buffer is defined as a receive buffer assigned 
to a specific tributary for its exclusive use, and in all cases the address of that tributary must 
be in BSEL3 of the assigning command. 

Private buffers and buffers from a common pool can be used jointly at control and tributary stations in 
a multipoint network. Under these circumstances, the advantages provided by both methods are avail- 
able to the user program. 

Private buffers can be set for unanticipated messages and/or abnormally large messages. 



The preceding information involved standard 18-bit addressing. However, the DMV11 may also oper- 
ate in 22-bit addressing mode. The DM VI 1 allows the software to set the 22-bit address mode of oper- 
ation. The bit indicating 22-bit address mode is set by the user program as part of a command when 
issuing transmit or receive buffers to the DMV11. The state of this bit is retained to indicate to the 
DM VI 1 the number of bits in the buffer address. 



3.4 DMV11 OUTPUT RESPONSES 

The DMV11 microcode has a set of three responses it can use to either reply to user-program com- 
mands or to inform the user program of error conditions. These responses are: 

• Buffer disposition response; 

• Control response; 

• Information response. 

As with input commands, each output response is identified by a typecode in bits zero, one, and two of 
BSEL2. 



NOTE 

In multipoint networks, each response issued con- 
tains (in BSEL3) the address of the tributary that 
relates to the response. However, in point-to-point 
networks, equivalent responses always contain a one 
in BSEL3. 
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3.4.1 Buffer Disposition Response 

This response is used to return both used and unused buffers to the user program. Figure 3-8 shows the 
format of this response and identifies the five methods of message disposition in BSEL2. BSEL2 bits 
zero, one, and two are encoded as follows: 



Bit2 


Bitl 


BitO 


Buffer Disposition 











Receive buffer complete 





1 


1 


Receive buffer unused 


1 








Transmit buffer complete 


1 


1 





Transmit buffer sent but not acknowledged 


1 


1 


1 


Transmit buffer not sent 



Receive Buffer Complete - When a message is received successfully and stored in the assigned main 
memory buffer, the DMV11 microcode notifies the user program by issuing a buffer disposition re- 
sponse with a type code of 000. Data in the receive buffer is not valid until such a response is issued. 
This response is issued for both common pool and private buffers. 

Receive Buffer Unused - When the protocol for a specified tributary is halted, the DMV11 automat- 
ically returns all associated private receive buffers to the user program. To do this the DM VI 1 issues a 
buffer disposition response with a type code of Oil for each outstanding buffer held by the specified 
tributary. This pertains to private buffers only. 
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Figure 3-8 Buffer Disposition Response Format 
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The DMV11 returns all common pool buffers if the user program issues a request halt state control 
command with a tributary address of zero. When all common pool buffers are returned, the DM VI 1 
issues an information response indicating that the process is finished. 

Transmit Buffer Complete - When a message is transmitted successfully, the DM VI 1 notifies the user 
program by issuing a buffer disposition response with a type code of 100. Successful transmission 
means that the receiving station has acknowledged receipt of the message. 

Transmit Buffer Sent But Not Acknowledged - When the protocol for a specified tributary is halted, the 
DMV11 automatically returns all transmit buffers currently being processed by that tributary to the 
user program. To do this, the microcode issues a buffer disposition response with a type code of 1 10 for 
each buffer sent but not acknowledged. 

NOTE 

During protocol operation, after seven unacknow- 
ledged transmissions of a message occur, the trans- 
mit threshold error is exceeded and the DMV11 is- 
sues a control response indicating this error (see 
Section 3.4.2). The DMVU continues to retransmit 
the message and responsibility for terminating the 
transmission belongs to the user program. 

Transmit Buffer Not Sent - DM VI 1 maintains a queue of buffers to be transmitted for each tributary 
address established in the network. When the protocol for a given tributary is halted, the DM VI 1 re- 
turns all unused buffers in the associated queue to the user program. To do this, the DMV11 issues a 
buffer disposition response with a type code of 1 1 1 for each transmit buffer remaining in the queue. 

The other CSRs used by the buffer disposition response are BSEL3, SEL4, and SEL6. The function of 
these CSRs is as follows: 

• BSEL3 specifies the tributary address associated with the buffer disposition response. 

• SEL4 and bits 14 and 15 of SEL6 contain the 18-bit buffer address for the buffer being 
completed or returned. For 22-bit address mode, bits 0-5 of BSEL6 are used with SEL4. 

• SEL6 (or SEL10 in 22-bit address mode), bits zero through 13, compose a 14-bit character 
count allowing for a maximum buffer size of 16,383 bytes. A character count returned by a 
buffer disposition response is designated in positive binary notation. 

Protocol is halted for a tributary in one of three ways when: 

1 . The user program issues a control command halting the tributary. 

2. A DDCMP STRT message is received while the tributary is in the run state. 

3. A DDCMP maintenance message is received, temporarily halting the protocol, while receive 
buffers are being returned. 

3.4.2 Control Response 

A control response is an unsolicited response issued by the DM VI 1 when an error is detected or when 
protocol information must be passed to the user program. The format for the control response is shown 
in Figure 3-9. BSEL3 contains the tributary address or character count, SEL4 and bits 8 through 1 3 of 
SEL6 contain the bus address for the affected buffer, and BSEL6 indicates the type of information 
being passed to the user program. In 22-bit address mode, SEL6 contains buffer address bits 16-21 and 
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BSEL10 indicates the type of information being passed to the user program. These types of information 
are indicated by an octal code and are listed in Table 3-7. Basically there are four categories of infor- 
mation. 

1 . System events 

2. Protocol events 

3. Network errors 

4. Procedural errors 



Table 3-7 Output Codes 



Octal 
Code 



Category 



Information 



002 



Network 
Error 



004 



Network 
Error 



006 



Network 
Error 



Receive threshold error - This error is reported to the user program when the 
number of consecutive receive errors equals seven. These receive error types 
are: 

1 . Message header blockcheck. 

2. Message data blockcheck. 

3. NAK in response to a DDCMP reply message. 

4. Buffer temporarily unavailable. 

5. Receive message overrun. 

6. Message header format error. 

7. When a message is too long for the 
available buffer. 

Each time the receive threshold error is reported, the counter is reset to zero. 

Transmit threshold error - This error is reported when the number of con- 
secutive transmit errors equals seven. These transmit errors consist of four 
types and occur when: 

1 . A STRT message is transmitted but not acknowledged within the timeout 
period. 

2. A STACK message is transmitted but not acknowledged within the 
timeout period. 

3 . A NAK is received in response to a transmission with a reason code other 
than REP response. 

4. A data message is transmitted but a reply was not received within the 
timeout period. 

Each time a transmit threshold error is reported, the transmit error counter is 
reset to zero, except when remaining in the DDCMP ISTRT and ASTRT 
states. 

Select threshold error - This error is reported when the selection interval time- 
out counter for a given station has timed out seven times. The selection inter- 
val is the time allocated for a tributary to respond to a poll or for a point-to- 
point station to respond to a transmission. 

Each time the select threshold error is reported, the selection error counter is 
reset to zero. 
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Table 3-7 Output Codes (Cont) 



Octal 
Code 


Category 


Information 






NOTE 

For more information on receive, transmit, or selec- 
tion threshold errors, see Section 5.3.3. 


010 


Protocol 
Event 


Start message received while running - This response indicates that a 
DDCMP STRT message was received from the station specified in BSEL3 
while this station was in the DDCMP run state. 

In normal operation, this message is used by a control station to inform a tri- 
butary that the control station has started protocol operation for that tributary. 

The start message is also used to resynchronize the logical link between a con- 
trol station and tributary. This might be necessary when message traffic is in- 
hibited because of threshold errors or receive or transmit overruns. 

When the DDCMP STRT message is received: 1) the DM VI 1 responds with 
start message received while running, and 2) the protocol at the tributary halts 
and all buffers are returned. 

At this time the logical link may be restarted (request start-up state control 
command). 


012 


Protocol 
Event 


Maintenance message received while running (or ISTRT or ASTRT) - This 
response indicates that a DDCMP maintenance message was received by a 
specific tributary while it was in the DDCMP run, ISTRT, or ASTRT state. 
This causes the tributary to notify the user program, return all unused buffers 
to the user program, and halt the protocol. The DMV11 then places the tri- 
butary in the maintenance state. The message that caused this event is lost. 


014 


Protocol 
Event 


Maintenance message received while halted - This response indicates that a 
DDCMP maintenance message was received by a specific tributary while it 
was halted. This places the tributary in the maintenance state. The message 
that caused this event is lost. 


016 


Protocol 
Event 


Start message received while in the maintenance state - This response in- 
dicates that a DDCMP STRT message was received by a specific tributary 
while it was in the maintenance state. No further action is taken by the micro- 
code. The user program determines what action to take based on this response. 


022 


System 
Event 


Tributary polling state dead - This response informs the user program at a 
control station that the specified tributary polling state has gone to the dead 
state. 

This response has no meaning in point-to-point networks. 
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Table 3-7 Output Codes (Cont) 



Octal 
Code 


Category 


Information 


024 


Protocol 
Event 


Run state - This response informs the user program at all stations that a spe- 
cific tributary has entered the run state. The DMV11 microcode issues this 
response as a result of receiving a request start-up state control command and 
having completed the DDCMP start-up sequence. 


026 


Network 
Error 


Babbling tributary - This response is issued to a user program to record the 
occurrence of a babbling tributary. It is only used by half-duplex point-to-point 
and multipoint control stations. 

A hflhhlino trihntarv is onf* which onntimips to transmit vfili'H pnntrnl mpcspopi; 

or message headers beyond the end of a programmable timeout (babbling tri- 
butary timeout counter). 

The babbling tributary response usually indicates a malfunction at the trans- 
mitting station or too short a period for the timeout counter. 

Recovery from this error condition generally requires human intervention at 
the remote station. 


030 


Network 
Error 


Streaming tributary - This response is issued to a user program to indicate 
that the remote station failed to release the channel at the end of the selection 
interval. It is only used by half-duplex point-to-point and multipoint control 
stations. 

Tnf* strpumino trihntnrv timpnnt nprinrl is HptprminpH hv tnp tirnoriimmshlp 
sli raining 11 1 uu idi j iiintsuui jjgiiuu 10 ucici uiiiivu uy inc pi ainiiiciuic 

streaming tributary timeout counter. The timeout period starts at the end of 
the selection interval. 

This error condition generally indicates a modem malfunction at the remote 
station or an inappropriate choice of the streaming tributary timeout counter. 

Recovery from this error condition generally requires human intervention at 
the remote station. 


32-76 


Reserved 




100-276 


Procedural 
Error 


Procedural errors - This response is issued by the DM VI 1 when the user pro- 
gram violates the procedures designated for interfacing the DMV11. In all 
cases, the event that caused the procedural error is ignored by the microcode. 
All procedural errors except octal codes 140, 300, and 302 are reported imme- 
diately to the user program. Those procedural errors are placed on the re- 
sponse queue. Specific procedural violations are identified by the octal code in 
BSEL6 as follows. 
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Table 3-7 Output Codes (Cont) 



Octal 
Code 


Category 


Information 






Code 


Description 






100 


A command other than a mode definition command is issued before 
the mode has been established. 






102 


Invalid type code used in a command. 






104 


Invalid mode change (for example, the mode of a tributary station is 
changed to point-to-point). 






106 


A nonglobal command is issued to an unestablished tributary. 






110 


A nonglobal command is issued having a tributary address of zero. 






112 


Attempt to delete or place an unhalted tributary in the start or 
maintenance protocol state. 






114 


Attempt to establish more than 12 tributaries. 






116 


Attempt to establish an already established tributary. 






120 


An invalid request key is used in a control command. 






122 


Attempt to assign a buffer for an unestablished tributary. 






124 


Attempt to assign a buffer for a halted tributary 






126 


Attempt to assign a buffer having a byte count of zero. 






130 


Attempt to assign a transmit buffer with a tributary address of zero. 






132 


Attempt to write or read and clear a reserved area of a tributary or 
global status slot. 






134 


Attempt to use the reserved bits in BSEL7 of control command. 






136 


Attempt to return all common receive buffers while the common 
buffer pool is being used. 






140 


Attempt to raise the common pool buffer quota to a value higher than 
376 octal. 






142-276 


Reserved 


300 


Procedural 
Error 


Buffer too small - This response informs the user program that the assigned 
receive buffer is not large enough for the current incoming message. Recovery 
from this error condition is detailed in Section 4.6.2.2. 
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Table 3-7 Output Codes (Cont) 



Octal 
Code 


Category 


Information 


302 


Procedural 
Error 


Nonexistent memory - This response is issued to the user program when the 
DMV11 microcode attempts to access a CPU memory location that does not 
respond. The address that caused the error is returned in BSEL4, BSEL5, and 
BSEL7 for this response. 

This error is fatal to the station that initiated the memory access causing the 
error. That station must be halted and restarted (see Section 4.6.2.1). 

NOTE 

With the exception of the buffer too small and non- 
existent memory errors, the only control response 
fields used by the DMV11 when posting a pro- 
cedural error are the type code field in BSEL2, and 
the output code field in BSEL6. All other fields re- 
main as set by the user program in the command 
that originally generated the procedural error. 


304 


System 
Event 


Modem disconnected - This response informs the user program that an on-to- 
off transition of the EIA signal data set ready (DSR) was detected. Such a 
transition indicates that the modem is disconnecting from the communications 
line. 

Since this is a global response, the content of BSEL3 is zero. 


306 


System 
Event 


Queue overflow - This response indicates that the free linked list is empty (see 
Section 4.6.2.3). 

This error typically indicates that for some reason output responses are being 
called for faster than the microcode can process them. 

NOTE 

This is a global fatal error and the DMV11 in- 
itializes itself after attempting to return all informa- 
tion (response queue only). 

Once this response is issued, the user program has three seconds to retrieve the 
next pending response from the CSRs. Three seconds are allowed for each 
pending response before the internal microdiagnostics clear the CSRs (see 
Section 4.3 for restarting). 


310 


System 
Event 


Modem carrier loss - This control response code informs the user program 
that the EIA signal carrier detect has gone from on to off while the DMV11 
was in the process of receiving a message. Since this is a global response, the 
content of BSEL3 is always zero. 
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BSEL5 
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Figure 3-9 Control-Out Command Format 18-Bit Mode 



3.4.3 Information Response 

An information response is issued by the DM VI 1 microcode in reply to a request for information by the 
user program. The format for this response is shown in Figure 3-10. The type code for this response is 
010 binary as indicated in BSEL2. BSEL3 contains the tributary address and SEL4 contains the infor- 
mation requested by the user program. If the information requested is from a GSS, BSEL3 contains a 
zero. 

An information response contains a return key code or a TSS or GSS address in BSEL6 bits 0-4. The 
return key codes are used in response to control request keys or protocol events and are encoded as 
shown in Table 3-8. The TSS address is used in response to a read or read and clear TSS/GSS com- 
mand in conjunction with bits 5 and 6 of BSEL6. 

Information responses to read or read and clear TSS/GSS control commands, use the TSS address 
field (bits 0-4 of BSEL6) to indicate the TSS or GSS location read. Bits 5 and 6 indicate whether the 
response is to a read or read and clear input command. 

3.5 TSS/GSS ACCESS 

When a user program accesses a TSS or a GSS through a control command, the DMV11 reads the 
designated location and passes the data to the user program by means of an information response. 
Reading a TSS or GSS location results in two bytes of data from that location being stored in BSEL4 
and BSEL5 of the information response, with the low-order byte in BSEL4, and the high-order byte in 
BSEL5. If a TSS is being read, BSEL3 in the information response contains the associated tributary 
address. However, data read from a GSS is passed to the user program through an information response 
having a zero in BSEL3. 

As described in Table 3-5, any TSS or GSS location can be read, and specific locations can be read and 
cleared. Along with the TSS/GSS address, BSEL6 in an information response also contains two single- 
bit fields that indicate a read or a read and clear TSS/GSS. These information response fields are 
described in detail below. 

TSS/GSS address This field (BSEL6, bits zero to four) contains the octal address of the 

TSS/GSS location from which the data in BSEL4 and BSEL5 is read. 

Read TSS/GSS When set, this bit (BSEL6, bit five) designates that BSEL4 and 

BSEL5 contain the data requested by the read TSS/GSS control com- 
mand. 
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Read and clear TSS/GSS When set, this bit (BSEL6, bit six) designates that BSEL4 and BSEL5 

contain the data requested by the read and clear TSS/GSS control 
command. In addition to reading the requested TSS/GSS location, the 
DMV11 also clears that location. 

NOTE 

The TSS/GSS locations accessible for writing, 
reading, and reading and clearing, are listed and de- 
scribed in Table 3-5. 
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Figure 3-10 Information Response Format 



Table 3-8 Return Keys for Information Response 



Octal 








Code 


Name 


Description 


10 


Return Modem 


This code indicates that BSEL4 and BSEL5 contain the requested modem 




Status 


status (see Appendix C). 


20 


Buffer Return 


This code indicates that the process of returning all buffers is completed. 




Complete 


Buffers are returned to the user program under the following circum- 
stances: 






1. 


The protocol event STRT message received while running occurred. 
This causes all private buffers assigned to the tributary designated by 
the address in BSEL3 to be returned. 






2. 


The protocol event maintenance message received while running 
occurred. This causes all private buffers assigned to the tributary 
designated by the address in BSEL3 to be returned. 






3. 


The user program issued a control command containing the request key 
request halt state causing all private buffers assigned to the tributary 
designated by the address in BSEL3 to be returned. 






4. 


The user program issued a global control command (BSEL3 = zero) 
containing the request key request halt state. This causes all unused 
common pool buffers to be returned. 






Information responses containing the return key code for buffer return 






complete always have zeros in BSEL4 and BSEL5. 
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CHAPTER 4 
PROGRAMMING TECHNIQUES 



4.1 INTRODUCTION 

Proper design of user programs for operation with DMVll-based multipoint and point-to-point net- 
works requires that consideration be given to a number of programming topics. This chapter discusses 
the following programming topics. 

• Command discipline and handshaking; 

• DMV11 start-up; 

• Criteria for determining user-defined parameters; 

• Error counter access; 

• Error recovery procedures; 

• Booting a remote station. 

These programming topics deal with interfacing the user program and DMV1 1 microcode by using the 
DMV11 command/response structure. 



4.2 COMMAND/RESPONSE DISCIPLINE AND HANDSHAKING 

The command/response interface between a DMV11 and the user program is accomplished through 
the DMV11 CSRs that are addressed through the CPU I/O page. 

Since the DMV11 runs in a multiprocessing mode with the associated CPU, the passing of commands 
and responses through this interface must be highly disciplined to eliminate the possibility of a race 
condition (the user program setting bits in the CSRs after the microprocessor has read those bits). This 
interface discipline requires that the user program follow two separate procedures; one for issuing com- 
mands, and one for retrieving responses. 

Figure 4-1 illustrates the control bits involved in CSR interface discipline. These bits are located in the 
DM VI 1 CSRs BSELO and BSEL2. Examination of Figure 4-1 shows that BSELO contains two control 
bits named interrupt enable in (IEI) and interrupt enable out (IEO), bits zero and four respectively. 
These bits when set, serve to enable the microprocessor to interrupt the main CPU under two circum- 
stances: 

1. When the CSRs become available for the issuing of a command after access is requested by 
the user program for that purpose (IEI and RDI). 

2. When the microcode has a response to be retrieved from the CSRs by the user program (IEO 
and RDO). 

NOTE 

Interrupt mode must be used, otherwise, receive 
overruns and transmit underruns are very probable. 
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NOTE 

It is recommended that the interrupt enable (IEI 
and IEO) bits be set when interfacing with the 
CSRs. It is imperative that they be set when 
operating at 56K b/s because the microprocessor 
is halted momentarily on every access to the 
CSRs. 

The procedures described below defining CSR interface discipline are based on operation in the inter- 
rupt mode. As a consequence, the IEI and IEO bits should be set by the user program prior to using the 
CSR interface. 
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Figure 4-1 CSR Interface Control Bits 



4.2.1 Command Discipline 

At start-up time, before the user program can execute any command, it must initialize the DMV11. 
This is accomplished by the program setting the master clear bit in BSEL1 and waiting for the DM VI 1 
to set the run bit. 

Once the DMV11 is initialized, commands may be issued. All commands are issued by the user pro- 
gram in two successive steps. The first step requests the use of the data port. The second step identifies 
the command type and the data port information for the appropriate command, and notifies the 
DMV11 that the command is in the CSRs. The specific content of each data port is further defined 
under each command description in Section 3.3. The handshaking procedure for input commands is as 
follows (see Figure 4-2). 

• The user program requests the use of the data port to issue a command by setting request in 
(RQI) bit 7 of BSELO. The user should also set bit of BSELO, interrupt enable in (IEI), at 
the same time (using the same instruction) to allow the DM VI 1 to interrupt the CPU when 
the data port is available. An interrupt is generated to XXO when RDI is asserted by the 
DMV11. 

NOTE 

The 22-bit mode is used when the software supports 
22-address bit buffers. A "one" in bit 3 of BSEL2 
indicates to the DMV11 that the software supports 
the change in the command format required to sup- 
port 22-address bits. 

• When the data port is available, the DMV11 informs the user by setting ready in (bit 4 of 
BSEL2) and generating an interrupt to vector XXO. 

• On detecting RDI bit set, the user can: 1) load the appropriate information into SEL4 and 
SEL6, and 2) load the input command code into bit 0-2 of BSEL2. 

• If a single command is to be issued, the user program clears RQI. If a series of commands 
are to be issued, RQI can remain set until just prior to the loading of the last command into 
the CSRs. By leaving RQI set while issuing a series of commands, the user program is as- 
sured of having access to the CSRs after the next response. 
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4.2.2 Retrieving Responses 

The DM VI 1 issues resppnses in two steps. If RDI is not set, the data pertinent to the responses being 
issued is loaded into BSEL3, SEL4, and SEL6. Once this is complete, the DMV11 sets the ready out 
(RDO) bit and the command code in BSEL2. An interrupt through vector XX4 is generated if the IEO 
bit is set. Generally, processing an output response involves the following steps: 

• The user program checks for RDO set. This is done by waiting for an interrupt. 

• To use the output interrupt capability, the user program must set the output interrupt enable 
bit in BSELO immediately after it detects that the run bit has been set following master 
clear. 

• When an RDO set condition is detected, the user program should move the contents of 
SEL2, SEL4, and SEL6 into a working storage area and clear RDO in BSEL2 as soon as 
possible. When RDO is cleared, the data port (SEL4 and SEL6) is released to the DMV11 
for more input or output processing. 



4.2.3 CSR Interface Interactions 

User-program access to the CSRs is under complete control of the DMV11 microcode. Access to the 
CSRs is granted upon request when the user program has a command to issue, or when the microcode 
has a response for the user program. Figure 4-2 illustrates the nature of the access window available to 
the user program under interrupt control, when issuing a command, or retrieving a response. As pre- 
viously indicated, the user program requests use of the CSRs for the purpose of issuing a command by 
setting RQI. The DMV11 microcode makes the CSRs available for the issuing of a command, only 
when it is not using them, by setting RDI and interrupting the user program through the floating vector 
XXO. As a result, the time period between the setting of RQI by the user program and the granting of 
the CSRs through an interrupt is indeterminate. 

When commands are being issued from a queue, and the last command has been issued with the user 
program still having ownership of the CSRs (RDI is set), there is a mechanism for returning the CSRs 
to the DMV11. In such cases, the user program can issue a control command with the code for no 
request in the request key field, thereby, signalling the microcode to ignore the contents of the CSRs. 
In this way, the possible reading of erroneous data by the DMV11 microcode is avoided. 

If the user program is to issue a single command, RQI should be cleared prior to issuing the command 
to the CSRs, as indicated in Figure 4-2. However, if a series of commands are to be issued, the user 
program can leave RQI set. In this circumstance, when a command is issued and RDI is cleared, the 
microcode relinquishes the CSRs to the user program as soon as they become available. The time peri- 
od between clearing RDO upon completing one command, and an interrupt initiating the next com- 
mand, is also indeterminate. 

When the DMV11 has a response to be passed to the user program, it sets RDO then interrupts the 
main CPU through the floating vector XX4. At this point, the user program has ownership of the CSRs 
and can proceed by reading the response. Once the response is read from the CSRs, the user program 
should immediately clear the RDO bit. User-program routines responsible for issuing commands and 
retrieving responses should limit the CSR access time required to load a command or retrieve a re- 
sponse. 



4.3 DMV11 START-UP 

Starting a DM VI 1 requires that the user program perform a series of steps to; 1) configure the DM VI 1 
to operate within the context of the associated network, 2) establish user-defined parameters, and 3) 
initiate protocol operations at the DMV11. 
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Figure 4-2 CSR Access Window 

4.3.1 Configuration Procedure 

The sequence to configure a DMV11 control and tributary station for network operation is formed by 
the following steps: 

1. Set the master clear bit and wait for the run bit to set. (See Section 3.3.1). 

2. When the run bit is set, read BSEL4 and BSEL6. 

3. If the contents of BSEL4 equals octal 33, and the contents of BSEL6 equals octal 305, the 
start-up diagnostics have successfully executed and the DM VI 1 is running. Any other value 
in BSEL6 indicates that an error condition was detected by the start-up diagnostics. The val- 
ues and meanings of these diagnostic error codes are listed in Table 4-1. 

4. If the DMV11 operational mode is software selectable, set the mode for that device by is- 
suing the appropriate mode definition command (see Section 3.3.2). If the mode for the 
DMV11 is selected by internal switches, this step can be ignored. 

4.3.2 Specifying User-Defined Parameters 

After a DMV11 is configured, the user parameters are specified. User-defined parameters include pa- 
rameters used by the polling algorithm, and parameters specific to protocol operation. In addition, 
those user parameters that are specific to the operation of tributaries, are stored in the tributary status 
slot (TSS) associated with each tributary. Parameters that are pertinent to overall system operation are 
stored in the global status slot (GSS) for the control or tributary station. 
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Table 4-1 Diagnostic Error Codes 



BSEL6 


BSEL4 


Description 


101 


N/A 


Branch test has failed and the microcode is spinning in a loop. 


102 


N/A 


6502 internal resister test has failed and the microcode is spinning in a loop. 


103 


N/A 


Load and store instructions test has failed and the microcode is spinning in a 
loop. 


104 


N/A 


Compare instructions test has failed and the microcode is spinning in a loop. 


105 


N/A 


Increment and decrement instructions test has failed and the microcode is 
spinning in a loop. 


106 


N/A 


Shift and rotate instructions test has failed and the microcode is spinning in 
a loop. 


107 


N/A 


Logic instructions test has failed and the microcode is spinning in a loop. 


110 


N/A 


Add with carry, subtract with carry, set and clear decimal mode instruc- 
tions test has failed and the microcode is spinning in a loop. 


111 


N/A 


Stack push and pull instructions test has failed and the microcode is spin- 
ning in a loop. 


112 


N/A 


Subroutine instructions test has failed and the microcode is spinning in a 
loop. 


113 


N/A 


Ram scratchpad, CSR, and NPR address resisters addressing test has failed 
and the microcode is spinning in a loop. 


114 


N/A 


Ram scratchpad, CSR, and NPR address resisters data test has failed and 
the microcode is spinning in a loop. 


115 


N/A 


True interrupt test has failed and the microcode is spinning in a loop. 


116 


N/A 


Ram data and addressing test has failed and the microcode is spinning in a 
loop. 


117 


N/A 


Ram alternating data test has failed and the microcode is spinning in a loop. 


120 


N/A 


Indexed indirect addressing mode instruction test has failed and the micro- 
code is spinning in a loop. 


121 


N/A 


Line unit message test has failed and the microcode is spinning in a loop. 


305 


33 


The microdiagnostics have completed without errors. 
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As described in Section 3.3.3, user parameters are specified through control commands configured to 
address a TSS or a GSS. These control commands write the data contained in BSEL4 and BSEL5 into 
the locations specified by bits 0-4 of BSEL6 (TSS or GSS address). In establishing polling and protocol 
parameters, the user program has the option of accepting the default for a parameter or setting the 
parameter to some predetermined value. Chapter 5 details the criteria to be used in determining opti- 
mum values for the various polling parameters. Criteria for determining the remaining parameters, 
which generally concern the operation of the communications link, are presented in Section 4.6. 

NOTE 

Although the majority of user-defined parameters 
are 1 6-bit s in length, some are single byte parame- 
ters. If the user program wishes to change one of the 
single-byte parameters and accept the default for the 
other, both parameters must be written. This is nec- 
essary because both TSS and GSS user-defined pa- 
rameters are written on 2- byte boundaries. 

The process of establishing user-defined parameters is presented as two separate steps: 

1 . Specifying user-defined parameters for control and tributary station TSS structures. 

2. Specifying user-defined parameters for control and tributary station GSS structures. 

4.3.2.1 Specifying TSS Parameters - TSS parameters that can be specified by the user program are 
listed in Table 4-2 by name, BSEL3 address, size, and default value. A functional summary of each 
parameter is also given. The actual order of setting TSS parameters through appropriately configured 
control commands is arbitrary. The complete command series to specify these parameters for TSS 
structures at a multipoint control station is listed below: 

1 . Issue a series of control commands to set the value for the transmit delay timer. This is re- 
ferred to as the preset value. 



2. Issue a series of control commands to establish the polling parameters Q and R for the three 
polling levels. 



3. Issue a series of control commands to specify values for the active, inactive, unresponsive, 
and dead polling state-change parameters. 



4. Issue a series of control commands to specify values for the maximum transmitted message 
count. 



5. Issue a series of control commands to set the selection timers for tributaries (or issue a single 
command to set the point-to-point station reply timer). 



6. Issue a series of control commands to set the babbling tributary timers. 



4-6 



Table 4-2 



User-Defined TSS Parameters 
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Table 4-2 User-Defined TSS Parameters (Cont) 



Name 


TSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 










one parameter is to 
be set to a unique 
value, and the de- 
fault is to be ac- 
cepted for the 
other, both the de- 
fault value and the 
unique value must be 
written. This para- 
meter is applicable 
only to the TSS 
structures at the 
multipoint control 
station. 


NDM-INACT 


234 


8 


10 


Number of no data 
messages required to 
go inactive: This is 
the number of con- 
secutive polls to be 
made (without re- 
ceiving a data mes- 
sage) before chang- 
ing the activity 
level of that tribu- 
tary from active to 
inactive. This para- 
meter is applicable 
only to the TSS 
structures at the 
control station. 


TO-UNRSP 


234 


8 


2 


Number of timeouts 
to go unresponsive: 
The number of conse- 
cutive polls of a 
tributary (without 
response) before 
changing the activi- 
ty level of that 
tributary from ac- 
tive or inactive to 
unresponsive. Both 
the NDM-INACT and 
TO-UNRSP counts are 
established through 
a single control 
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Table 



4-2 User-Defined TSS Parameters (Cont) 



Name 


TSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 










command. Therefore, 
if one parameter is 
to be set to a 
unique value, and 
the default is to be 
accepted for the 
other both the de- 
fault value and the 
unique value must be 
written. This para- 
meter is applicable 
only to the TSS 
structures at the 
multipoint control 
station. 


TO-DEAD 


235 


8 


20 


Number of timeouts 
to go dead: The num- 
ber of consecutive 
polls of an unres- 
ponsive tributary 
(consecutive selec- 
tion timeouts) be- 
fore the activity 

level nf tViat trihn- 

tary is changed from 
unresponsive to 
dead. This para- 
meter is applicable 
only to the TSS 
structures at the 
multipoint control 
station. 


MXMC 


235 


8 


4 


Maximum transmitted 
message count: This 
parameter is a count 
of the maximum num- 
ber nf jiHiittinf* Hfita 

messages to be 
transmitted by a 
station before it 
deselects itself. 
This count applies 
to the TSS struc- 
tures at both con- 
trol and tributary 



4-9 



Table 4-2 User-Defined TSS Parameters (Cont) 



Name 


TSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 










stations in multi- 
point networks as 
well as point-to- 
point stations. Both 
TO-DEAD and MXMC 
for a given tribut- 
ary are established 
through a single 
control command. 
Therefore, if one 
parameter is to be 
set to a unique 
value, and the de- 
fault is to be ac- 
cepted for the 
other, both the 
default value and 
the unique value 
must be written. At 
tributary and point- 
to-point stations, 
the polling para- 
meter TO-DEAD is ig- 
nored. 


SEL 
TIMER 


236 


16 


3 (seconds) 
(5670 Octal) 


Selection interval 
timer: This timer 
is started when a 
message is trans- 
mitted with the 
select flag set, and 
halted when a valid 
reply is received or 
the line is resynch- 
ronized. The selec- 
tion timer is used 
as a reply timer for 
full-duplex point- 
to-point networks 
(see Section 4.4.1). 
It is used as the 
select timer at mul- 
tipoint control sta- 
tions, and in half- 
duplex point-to- 
point networks. This 
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Table 4-2 User-Defined TSS Parameters (Cont) 



Name 


TSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 










counter counts in 
milliseconds (ms) 
from 1 to 65,535 ms. 


BAB 
TIMER 


237 


16 


6 (seconds) 
(13560 Octal) 


Babbling tributary 
timer: This timer 
is used to detect 
a babbling tribut- 
ary (see Section 
4.4.2). In a 
multipoint network 
this parameter is 
applicable only to 
the control station. 
However, this para- 
meter is applicable 
to both stations in 
point-to-point net- 
works operating 
half-duplex. 



4.3.2.2 Specifying GSS Parameters - As previously indicated, when one or more tributary addresses 
are established at a DMV1 1, the DMVll's microcode automatically creates a GSS for that control or 
tributary station. The GSS parameters that can be specified by a user program are listed in Table 4-3 
by name, BSEL3 address, size, and default value. A functional summary of each parameter is also 
given. If a value is not specified for a parameter the microcode uses the default value. Specifying a 
user-defined GSS parameter requires that BSEL3 in the pertinent control command contain zero. The 
control commands necessary to specify GSS parameters for a multidrop station are listed below: 

1 . A control command to specify the number of sync-characters (NUM SYNC) that are to pre- 
cede nonabutting transmit messages. 

2. A control command to set the streaming tributary timer. 



3. Three control commands to establish values for the global polling parameters delta time 
(DELTA T), dead tributary (DEAD T), and poll delay, respectively. 

Specific user-defined TSS and GSS parameters are common to both control and tributary stations. 
Note that control commands specifying TSS parameters must have the address of the tributary associ- 
ated with the TSS being accessed in BSEL3. Similarly, each control command specifying a GSS pa- 
rameter must have BSEL3 set to zero. Since the prior steps have covered user-defined TSS and GSS 
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parameters (see Table 4-2 and 4-3) at the control station, the two steps listed below complete the pa- 
rameter-specifying process at the tributary stations: 

1 . Issue a series of control commands at each tributary station to set the maximum transmitted 
message count (MXMC) for each active TSS in a tributary station TSS structure. Note that 
the 8-bit value for MXMC must be placed in BSEL5 of each command (the tributary station 
microcode ignores BSEL4 in these commands). The procedure for determining an optimum 
value of this parameter for tributary stations is the same one used for control stations. 

2. Issue a single control command at each tributary station to set a value for the number of 
sync-characters (NUM SYNC) that are to precede nonabutted transmit messages. The pro- 
cedure for determining an optimum value of this parameter for tributary stations is the same 
one used for control stations. 



Table 4-3 User-Defined GSS Parameters 



Name 


GSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 


NUM SYNC 


. 233 


16 


10 (low 
speed) 
15 (high 
speed) 


Number of sync-characters: 
This global value speci- 
fies the number of sync- 
characters that are to 
precede nonabutting trans- 
mitted messages. This 
parameter applies to all 
stations. Low speed is 
defined as less than 56K 
b/s, and high speed is 56K 
b/s. 


STREAM 
TRIB 


234 


16 


6 (sec.) 
(13560 
Octal) 


Streaming tributary timer 
preset: This timer is used 
to detect a streaming tri- 
butary (see Section 4.4.3) 
and Table 3-7). In a mul- 
tipoint network, this 
parameter is applicable 
only to the control sta- 
tion. However, in point- 
to-point networks, this 
parameter is applicable to 
both stations. 


DELTA T 


235 


16 


200 (ms) 

(310 

Octal) 


Delta time: This is the 
polling algorithm update 
increment. This global 
parameter, which is ap- 
plicable only to multi- 
point control stations, 
is used by the polling 
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Table 4-3 User-Defined GSS Parameters (Cont) 



Name 


GSS Addr 

(Octal) 

BSEL6 


Size 
(Bits) 


Default 
(Octal) 


Description 










aigoriinm 10 Calculate 
polling urgency (see 
Section 5.2.1). The de- 
fault value of 200 ms is 
the minimum value for this 
parameter. DELTA T is also 
used as the interval for 

U^JUcLLlilg Lilt LldlliMllll 

delay timer. 


DEADT 


236 


16 


10 (sec.) 

(17500 

Octal) 


Dead timer: This is the 
interval between polls for 
dead tributaries. This 
global parameter applies 
only to multipoint control 
stations. 


POLL 
DELAY 


237 


16 


0(no 
delay) 


This parameter provides 
for a fixed delay between 
polls for all tributaries 
in a network. If the de- 
fault is accepted, the 
next poll for any tribu- 
tary occurs immediately 
following the current 
poll. 



4.3.3 Protocol Operation 

At this point the DM VI 1 has been configured for operation in the associated network and is ready for 
protocol operation. The steps required to initiate protocol operation are: 

1. Place established tributaries in the ISTRT state by issuing one control command containing 
the request key. Request ISTRT state for each tributary address. 

2. If the DMV11 is a station in a point-to-point network, one control command must be issued 
containing the request ISTRT state request key with a tributary address of one in BSEL3. 

3. The DMV11 confirms that the protocol is operational at each tributary by issuing a control 
response (one for each control command issued) containing the protocol event code for 
DDCMP run state entered. 

4.4 CRITERIA FOR DETERMINING COMMUNICATIONS LINK PARAMETERS 

User-defined TSS and GSS parameters fall into two categories: polling parameters that provide for 
user-program control over the dynamic activity of the polling algorithm, and communications link pa- 
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rameters that provide the user program with the ability to regulate data traffic over the physical com- 
munications line. Referring to Tables 4-2 and 4-3, the communications link parameters include: 

• Selection interval timer, 

• Number of sync-characters, 

• Babbling tributary timer, 

• Maximum transmitted message count, 

• Streaming tributary timer, 

• Transmit delay timer. 

Values for the selection interval timer and the number of sync-characters are interrelated, as are values 
for the babbling tributary timer and the maximum transmitted message count. These interrelated pa- 
rameters are described in Sections 4.4.1 and 4.4.2. 

4.4.1 Setting the Selection Interval Timer 

The function performed by the selection interval timer at a DMV11 depends on the mode selected for 
that DM VI 1. In full-duplex point-to-point networks, this timer is used as a reply timer for the purpose 
of message accountability. This timer serves as a selection interval timer when the mode for the associ- 
ated DM VI 1 is one of the following: 

• A full-duplex control station; 

• A half-duplex control station; 

• A half-duplex point-to-point station. 

In this capacity, it performs the link management function and provides for message accountability. 

Link management is the process of controlling the transmission and reception of data over networks 
where there are two or more transmitter/receiver devices actively connected to the same physical com- 
munications link. This applies to half- and full-duplex multipoint networks as well as half-duplex point- 
to-point links. On half-duplex links, only one transmitter can be active at any time, and on full-duplex 
links, only one slave transmitter can be active at a time. 

A station on such links can transmit when it is selected or granted ownership of the link. Link ownership 
is passed through use of the select flag in the DDCMP message header. Detecting a select flag in a 
received message allows the receiving station to transmit after message reception is completed. Sending 
a select flag means that the transmitting station ceases transmitting after the current message is sent. 

A selection timer detects the loss of a select flag by timing the interval required to receive the longest 
message from a station. A timer is started when a station is selected and reset when valid messages are 
received from that station. When the timer interval is exceeded at the sending station (a message was 
not received during the period of the timer) it is assumed that messages with the select flag were either 
transmitted or received in error. 

At this point, the station that originally sent the messages with the select flag set assumes ownership of 
the link. This station resumes transmitting as if it had received a valid select return. 

The values assigned to select interval timers at stations in half-duplex point-to-point networks should be 
different at both stations to avoid possible deadlock race conditions. For both multipoint control stations 
and half-duplex point-to-point stations, the criteria for determining the value for a select timer includes 
such factors as: 

• Maximum message length; 

• Number of sync-characters; 

• Line speed; 

• Line turnaround time; 

• Message processing delays. 
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As indicated in Table 4-3, the GSS parameter number of sync-characters has two defaults; one for low- 
speed operation (10), and one for high-speed operation (15). The operational speed range of a DM VI 1 
is specified by the line unit low-speed/high-speed switch which is placed in the appropriate position 
when the DMV1 1 is hardware configured (see Section 2.5). In the low-speed position the DMV1 1 can 
operate at line speeds up to 19.2K b/s, and in the high-speed position the device line speed is 56K b/s. 
It is recommended that the default for the appropriate line speed range be taken for this parameter. 

Some recommended values for a selection interval timer are given in Table 4-4. The calculations shown 
in Table 4-4 include the following overhead factors: 

256 bytes of data 
28 bytes of header, sync, and pad characters 



Total 284 bytes 

The formula used to derive the values listed in Table 4-4 is: 
8 bits per byte 

X 284 bytes per message + RTS/CTS delay = Timer value (in seconds) 

baud rate (bits 
per second) 

NOTE 

Most modems include an RTS/CTS delay that must 
be included in the calculation of the value for the se- 
lection interval timer. When operating with an exter- 
nal (EI A) modem, the typical delay used is 150 ms. 
The delay used when operating with the integral 
modem is 100 [is. 



Table 4-4 Recommended Selection Interval Timer Values 



Bits Per Second 


Calculated Timer Value for a 256 Byte Message 


4.8K 


473 ms + 150 ms = 623 ms (700 ms) 


9.6K 


236 ms + 150 ms = 386 ms (400 ms) 


56K 


40.5 ms + 0.1 ms = 40.6 ms (50 ms) 



The values listed in Table 4-4 represent absolute minimums. In most cases, specific applications require 
additional delay time over these values to prevent a timeout during reception of a valid message. Re- 
quirement for additional delay time can be caused by processing delays that occur when receiving from 
a non-DMVl 1 device, or by line delays encountered when dealing with satellite networks. When deter- 
mining this value, keep in mind that it represents the time the system can reasonably expend waiting for 
a response from another station. 

When used as a reply timer, the selection interval timer sets the maximum waiting period between send- 
ing a message and receiving an acknowledgement before taking error recovery actions. This timeout is 
necessary to recover from outages and the distortion of messages by the link. This timeout also prevents 
the protocol from being deadlocked. 
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The same criteria used to determine a value for a selection interval timer in multipoint networks, are 
also used to determine a value when this timer is used as a reply timer. As shown in Table 4-2, the 
default value for both cases is three seconds. 



4.4.2 Setting the Babbling Tributary Tinier 

This user parameter is applicable to half-duplex and full-duplex multidrop network control stations. A 
babbling tributary is a tributary that continues to transmit valid DDCMP messages after a program- 
mable timeout has expired, thereby, denying equal access to other nodes. This situation is controlled by 
the babbling tributary timer which monitors the total time period a tributary continuously transmits 
without relinquishing the communications line. When this period exceeds the timeout period of the 
babbling tributary timer, the user program is notified through a control response. The control response 
contains the code for a babbling tributary along with the identity of the offending tributary. When a 
babbling tributary is detected, the control station takes no action beyond this notification. 

A major consideration in determining a value for the tributary timer is the total time interval that a 
given tributary requires to end a selection interval. Determining the value for this timer is similar to 
that for the selection interval timer because the same range of factors are used as criteria for calcu- 
lating the value. The main difference in the two determinations is that the total number of message 
bytes should be used in babbling tributary timer parameter calculations rather than the number of 
bytes in the longest message. 

A value for the maximum transmitted message count parameter must also be considered in conjunction 
with the parameter for the babbling tributary timer. The user-defined parameter to set this counter 
places a limit on the number of messages that a tributary can transmit during the selection period. This 
is done by forcing the select flag when the count of messages received from a tributary equals the value 
of the maximum transmitted message count. This count relieves the user program from having to limit 
the number of messages queued for transmission in order to avoid a babbling tributary condition. 

In any case, the period established for the timeout of a babbling tributary timer should be long enough 
to ensure that timer expiration definitely indicates an error condition. In addition, the parameter as- 
signed to the maximum transmitted message count should also be considered when establishing the pe- 
riod of the babbling tributary counter. 

4.4.3 Setting the Streaming Tributary Timer 

A streaming tributary is a tributary station on a multipoint line (or an associated point-to-point station) 
that continues to assert the carrier signal on the link after it has relinquished ownership of the link. In 
normal operation, ownership of the link is returned to the control station when it receives a select flag or 
the period of the selection interval timer is exceeded. A timeout of the streaming tributary timer in- 
dicates a potential jamming of the link by a defective tributary station, a defective point-to-point sta- 
tion, or a malfunctioning modem. 

The streaming tributary is started when ownership of the link is granted to the control station by the 
remote station, and stopped when the carrier is dropped by that station. When a streaming tributary is 
detected, through expiration of the streaming tributary timer, the user program is notified in the same 
manner as with a babbling tributary. The control station does not transmit until the carrier is dropped. 1 

Determination of a value for the streaming tributary timer requires consideration of such factors as 
settling time of the communications line and modem delays. As with determining periods for the selec- 
tion interval timer and the babbling tributary timer, the period specified for this timer should be long 
enough to preclude premature expiration of the timer. For most network applications the default of one 
second is sufficient. 
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4.5 ERROR COUNTER ACCESS 

The DMV11 is equipped with a large compliment of error counters designed to isolate a wide range of 
error conditions. The TSS for each established tributary contains seven error counters along with three 
statistical counters that provide background information for error analysis. In addition, the GSS at each 
station contains four error counters that tabulate errors that are global to the station. The three TSS 
statistical counters are 16 bits in length, and the threshold error counters are three bits in length. The 
remaining TSS/GSS error counters are eight bits long. 

4.5.1 Reading the Counters 

Both TSS and GSS counters are accessed through an appropriate control command with the content of 
the requested counter or counters being returned through an information response (see Sections 3.3 and 
3.4). Through the control command, the user program has the option of reading, or reading and clearing 
the counters. When doing error analysis it is recommended that a user program read and clear these 
counters to assure a zero-base for subsequent sampling of the counters. If copies of the counters are 
being maintained in main CPU memory, it is also recommended that counters be read and cleared. 

NOTE 

The three-bit threshold error counters are automat- 
ically reset when the maximum count is reached so 
that access to these counters is restricted to reading 
only. 

The DM VI 1 error and statistical counter structure is designed to be complimentary. As an example of 
this complimentary structure, consider the data errors inbound counter and the data messages received 
counter. The data errors inbound counter tabulates the errors related to the validity of message recep- 
tion such as block-check errors, whereas, the data messages received counter records the total number 
of messages received. A ratio of message reception errors to total number of messages received can be 
derived from these two counters. 

4.5.2 Counter Skew 

When performing error analysis, there is a potential of skew between counts due to read time lags and 
the requirement that counters be read one at a time. The probability of skew between counts is a func- 
tion of line speed; the higher the line speed, the greater the probability of a skew condition. An example 
of this potential skewing is the possible discrepancy between the number of selection intervals and the 
number of selection timeouts. A skew could result from additional selection timeouts occurring while 
the counters are being read. 

If circumstances require that error/statistical counters be read without the potential for skew, this can 
be done by halting the protocol at the tributary. With the protocol halted, the contents of the er- 
ror/statistical counters in a TSS and in the GSS are frozen at the counts recorded when the protocol 
was halted. The counters can then be read without the problem of skew due to read time lags. 

4.6 ERROR RECOVERY PROCEDURES 

Within a DMVll-based network, there are three basic levels of error recovery involving the user pro- 
gram: 

1 . Procedural violations where only the user program is notified. 

2. Recovery from errors requiring protocol shutdown initiated by the user program. 

3. Fatal errors resulting in system shutdown with minimal notice to the user program. 

Referring to Table 3-7, procedural error codes from 100 to 140 are reported to the user program with 
no recovery required. The remaining two procedural errors (codes 300 and 302) involve error recovery 
levels two and three respectively. All network errors require recovery through protocol shutdown, and 
the control response (queue overflow) could result in network shutdown. 
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4.6.1 Recovery from Network Errors 

In all cases, recovery from network errors requires that the protocol be halted at the tributary or station 
recording the error. Two similar but separate procedures are recommended for recovery from threshold 
errors, and babbling and streaming tributary errors. These recovery procedures are described below. 

4.6.1.1 Recovery from Threshold Errors - DM VI 1 threshold errors are detailed in Section 5.3.3. The 
recommended recovery procedure to be initiated by the user program at the station recording the errors 
is presented below: 

1. Halt the protocol (see Table 3-6). 

2. Read the error counters to determine the nature and cause of the threshold error condition. If 
the error results from a shortage of receive buffers, correct the condition. If the transmit or 
selection threshold is being exceeded, check the operational condition of the remote station. 

3. When the conditions causing the errors have been eliminated, restart the protocol (see Sec- 
tion 4.3.3). 

4.6.1.2 Recovery from Babbling and Streaming Tributary Errors - Babbling or streaming tributary er- 
rors are created when their respective timers are exceeded. Therefore, a timeout can result from an 
actual error condition, or because the period of the timer is too short for the type of message activity on 
the line (see Sections 4.4.2 and 4.4.3). A suggested recovery procedure to be used when encountering 
these conditions is: 

1 . Halt the protocol. 

2. Check the value of timer parameters and increase if the value is not appropriate. 

3. Restart the protocol (see Section 4.3.3). 

4. If this error condition persists, reconfigure the station as specified by Section 4.3.1. 

5. When the cause of the timeout originates at the remote station, action must be taken at the 
remote station to ascertain and correct the fault. The local station is at fault only if the values 
of the timer parameters are inappropriate. 

4.6.2 Recovery from Procedural Errors 

The three procedural errors that require a recovery procedure are: 

1 i Nonexistent memory error. 

2. Buffer too small error. 

3. Queue overflow error. 

The recovery procedure for each of these errors is detailed in Sections 4.6.2.1 through 4.6.2.3. 

4.6.2.1 Recovery from a Nonexistent Memory Error - Nonexistent memory errors occur when the 
DM VI 1 tries to access an allocated receive or transmit buffer having an invalid bus address. When this 
error is detected, the DMV11 posts a control response to the user program containing the invalid ad- 
dress (see Section 3.4.2). It is up to the user program to determine whether the nonexistent address 
concerns a transmit or receive buffer. 

NOTE 

Depending on microcode processing circumstances, 
the nonexistent memory address returned to the user 
program could have been incremented to the next se- 
quential location. 
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The suggested recovery procedure for this error is as follows: 

1. Halt the protocol for the tributary or station recording this error to initiate return of all out- 
standing buffers. 

2. If the error concerns a buffer from the common pool, the user program should issue the glob- 
al halt command to initiate return of all outstanding receive buffers from the common pool. 

3. Restart the protocol and reallocate buffers as necessary. 

Persistent recurrence of this error indicates a possible main CPU or DMV11 malfunction. 

NOTE 

If the network line speed is 56K b/s, the requests for 
retransmission generated by a nonexistent memory 
address can result in the overflow of the DMV11 re- 
sponse queue causing a fatal system error (see Sec- 
tion 4.6.2.3). 

4.6.2.2 Recovery from a Receive Buffer Too Small Error - When the DMV11 receives a message, it 
first checks for the availability of a buffer from the common buffer pool linked list, and if one is avail- 
able, it uses that buffer. If the common buffer pool is empty or not enabled, the private buffer linked 
list is checked. If a private buffer is not available, the receiving station NAKs the incoming message. 
The steps taken by the DMV1 1 microcode in this process are listed below. 

1. Is the message number in sequence? Yes, continue; No, ignore message. 

2. Is the common buffer pool enabled? Yes, continue; No, go to Step 6. 

3. Is the common buffer pool quota = 0? Yes, go to Step 6; No, continue. 

4. Is a common pool buffer available? Yes, continue; No, go to Step 6. 

5. Is the common pool buffer too small? Yes, go to Step 8; No, use this buffer. 

6. Is a private buffer available? Yes, continue; No, send NAK - buffer temporarily unavailable. 

7. Is private buffer too small? Yes, send NAK - buffer too small; No, use this buffer. 

8. Is private buffer available? Yes go to Step 7; No, send NAK - buffer too small. 

NOTE 

The DMV11 does not scan the common pool or pri- 
vate linked list structures looking for a buffer of suf- 
ficient size. Rather, it uses the next available buffer 
from the list. 

Buffer too small errors apply only to receive buffers. The procedure for recovery from this error is 
dependent on whether the allocated buffer is from the common pool or is a private buffer. The appli- 
cable recovery procedures are explained below. 

A. Common pool buffer too small 

1. Assign a private buffer of sufficient size to the receiving tributary through a buffer ad- 
dress/character count command (see Section 3.3.4). 
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B. Both private and common pool buffers too small 

1. Halt the protocol for the offending tributary to initiate return of all outstanding private buf- 
fers. 

2. Restart the protocol. 

3. Assign a private buffer of sufficient size to the receiving tributary through a buffer ad- 
dress/character count command (see Section 3.3.4). 

C. Private buffer too small, and common pool not enabled 

1. If buffers from the common pool are available to other tributaries, and are of sufficient size, 
enable common pool buffers for this tributary (see Section 3.3.4). 

2. If the common buffer pool is not in use for other tributaries, follow recovery procedure B 
above. 



4.6.2.3 Recovery from a Queue Overflow Error - This error is always fatal to the DM VI 1 recording 
the error since it. forces automatic shutdown of the device. The basic cause of this error is the in- 
availability of link blocks from the free linked list (see Section 5.4.1.1). Typically, this error results 
when the internal response queue overflows because the DMV11 generated responses faster than the 
user program could retrieve responses from the queue. This error can also occur if an inordinate num- 
ber of receive buffers have been allocated. One cause of response queue overflow is the occurrence of 
repetitive nonexistent memory errors in high-speed networks (see Section 4.6.2.1). 

When this error occurs, the DMV11 posts the most current entry in the response queue to the user 
program. The user program then has three seconds after being interrupted to retrieve the response. If it 
is retrieved during this three second window, the next response is posted. As long as the user program 
retrieves each response within this window, the process continues until the internal response queue is 
empty. These responses can then be analyzed to determine the cause of the queue overflow. 

After the last response has been posted, or the three second response period has expired, the DM VI 1 
shuts itself down. At this point, returning the DMV11 to operational status requires that the start-up 
procedure be initiated from the beginning (see Section 4.3). 



4.7 BOOTING A REMOTE STATION 

DMVll-based networks provide the user program, at the multipoint control station or point-to-point 
station, with the ability to boot the main CPU at a remote station that has been shut down due to power 
outage or software malfunction. There are three ways this boot function can be performed: 

1 . Remote load detect: The control station starts the primary MOP boot procedure for a remote 
station. 

2. Power-on boot: The first poll received after power-up at the remote station causes the 
DM VI 1 at that station to request that the control station start the MOP boot procedure. 

3. Invoke primary MOP: The user program at the remote station causes the DM VI 1 to request 
that the control station start the primary MOP boot procedure. 
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NOTE 

Control station is either a multipoint control or 
point-to-point station that is transmitting (over the 
link) the boot or requested program to the remote 
station. Remote station is either a multipoint tri- 
butary or point-to-point station that is receiving 
(over the link) the boot or requested program. 

NOTE 

Power-on boot, remote load detect, and invoke 
primary MOP are not mutually exclusive. All three 
features could be used in a particular application. 

Primary MOP boot procedures require that the DM VI 1 be switch-configured in the manner specified 
in this section. The steps taking place at the remote station and over the communications line leading to 
each of the three primary MOP boot functions are presented in the following sections. 

4.7.1 Steps Leading to a Remote Load Detect Boot 

The steps taking place at the DMV11 remote station and its host CPU in response to an enter MOP 
mode message from the control station are: 

1. The DM VI 1 NPRs a tight-loop routine into main memory. 

2. The DM VI 1 transfers control to the routine through the power fail/restart vector. This rou- 
tine inactivates the CPU to prevent any intervention during the NPR process. 

3. The DM VI 1 then sends a primary MOP request program message to the control station. The 
control station responds in turn with a primary MOP memory load with transfer address mes- 
sage containing the boot or related program to be loaded into main memory at the remote 
station. 

4. The DM VI 1 NPRs that program into main memory, then starts executing the program. 

5. At this point the remote station is operating in the manner intended by the down-line loaded 
program. 

The steps occurring over the communications line during a remote load detect boot are: 

1 . The control station sends an enter MOP mode message to a remote station. 

2. The remote station recognizes the address and password in the message, then inactivates its 
host CPU. 

3. The remote station then responds with a primary MOP request program message. 

4. The control station responds to this message with a primary MOP memory load with transfer 
address message containing the boot or related program to be loaded into the host CPU at the 
remote station. 

4.7.2 Steps Leading to a Power-On Boot 

When power is restored after a shutdown at a remote station, the DM VI 1 performs the same steps used 
during a remote load detect boot. However, the first two steps performed over the communications line 
are omitted, and the tributary station responds to the first poll from the control station with an MOP 
request program message. The same sequence used in the remote load detect boot procedure is then 
followed. 
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4.7.3 Steps Leading to an Invoke Primary MOP Boot 

This boot operation is initiated when a user at a remote station sets the boot and master clear bits in the 
DMV1 1 initialization register (see Section 3.3.1). The steps taken by the DMVl 1 are the same as with 
a power-on boot. 



4.7.4 DMV11 Switch Settings for the Boot Functions 

At remote stations, in networks supporting the primary MOP boot functions, the switches must be con- 
figured in a specific way in order to properly perform the boot functions (see Section 2.5 and Table 2- 
6). 

NOTE 

The switch setting procedures described below apply 
only to tributary stations in a multipoint network 
and one node in a point-to-point network. 

The unit number (zero or one) of each DMVl 1 must be appropriately set. This number allows the boot 
!_ program, once it is loaded into the host CPU, to identify the specific DMVl 1 (within the host's floating 
address space) performing the boot. 

NOTE 

When primary MOP booting is supported in a net- 
work, the operating mode of each tributary station 
eligible for booting must be set in the switches rather 
than through the mode definition command. 

The operating mode of a DMVl 1 is specified by setting the mode enable switch to one (OFF) (switch 
number 1 of the boot enable switch pack), and setting switches numbered 6, 7, and 8 to the required 
operating mode. The settings for these switches are listed in Table 4-5. 

4.7.4.1 Switch Settings for the Power-On Boot Function - To enable the power-on boot function at a 
remote station, switch number 4 of the boot enable switch pack (power-on boot) must be set to one 
(OFF). In addition, the tributary address of this station must be set in the DDCMP address switch 
pack. 

4.7.4.2 Switch Settings for the Invoke Primary MOP Boot Function - The DMVl 1 switch settings for 
the invoke primary MOP boot function are the same as those for the power-on boot function. However, 
the setting of the power-on boot switch has no affect on the invoke primary MOP boot. 

An additional feature of the invoke primary MOP boot is that it may allow the tributary address of the 
remote station to be software assigned instead of switch assigned. This feature is only valid for remote 
stations that are multipoint tributaries. To use this feature, the following conditions must exist. 

• The tributary address/password in the DDCMP address switch pack must be zero. 

• The user program at the remote station must have established the tributary using the control 
command (establish tributary). If the remote station is using the multiple address tributary 
option, the tributary address used for booting must be the first one established. 

NOTE 

Invoke primary MOP boot with the software-as- 
signed tributary address does not work if the power- 
on boot switch is enabled. 
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Table 4-5 Mode Switch Settings 



Mode 
Switches 


Characteristics 


Configuration 


uivii_ii Line 
Compatibility 


6 7 


8 








ON ON 


ON 


Half-duplex 


Point-to-point 


Yes 


OFF ON 


ON 


run-aupiex 


Point-to-point 


Vac 

Yes 


ON OFF 


ON 


Half-duplex 


Point-to-point 


No 


OFF OFF 


ON 


Full-duplex 


Point-to-point 


No 


ON ON 


OFF 


1 I oil Hll *\ 1 s^mr 

riau-Qupiex 


Multipoint control 
station 


XT / A 
IM /A 


OFF ON 


OFF 


Full-duplex 


Multipoint control 
station 


N/A 


ON OFF 


OFF 


Half-duplex 


Multipoint tributary 
station 


N/A 


OFF OFF 


OFF 


Full-duplex 


Multipoint tributary 
station 


N/A 



4.7.4.3 Switch Settings for the Remote Load Detect Boot Function - To enable the remote load detect 
boot function at a remote tributary station, switch number 5 of the boot enable switch pack (enable 
remote load detect) must be set to one (OFF). For the remote load detect boot function, the switch- 
specified tributary address also serves as the password which is contained in the enter MOP mode mes- 
sage. 

When using boot functions in point-to-point networks, the tributary address/password switches can, for 
security purposes, be set to a unique value since the address of a point-to-point node is always known to 
be one. 

4.8 MAINTENANCE REGISTER EMULATION 

The DM VI 1 is placed into maintenance mode when the user program sets bits and 6 at the same time 
in BSEL1. When this happens, the microcode enters a maintenance loop and sets MNT RDY (bit 7 of 
BSEL2) to indicate that the microcode is ready to receive a command as defined by bits zero through 
three of BSEL2 (see Figure 4-3). The functions of these commands are described in Table 4-6. 

NOTE 

The microdiagnostics must complete tests 1-12 as a 
minimum before allowing entry into the maintenance 
loop. 

In the maintenance mode, the functions of the CSRs are redefined as follows: 

• BSELO, bits zero and four, enable the respective microprocessor LSI bus interrupts as de- 
fined by bits one and two. See Figure 4-3. 
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• BSEL2, bits zero through three, define the maintenance loop command function. Bits four 
and five are used for interrupting the CPU if an internal microprocessor interrupt occurs. 
These interrupts are enabled by BSELO. Bit seven is set by the microprocessor when the 
maintenance loop is ready to receive another command function in bits zero through three 
(Table 4-6). 

• SEL4 contains a DMV11 memory location for function codes one through five (Table 4-6). 

• SEL6 contains data written or read for functions one, two, and six. It also contains a 16-bit 
address for functions three and four. 

• SEL10 contains the upper address bits for functions three and four. Only the low byte of this 
CSR is used. 

NOTE 

BSEL10 and 11 are only used in 22-bit mode. 
BSEL12 through 17 are not shown because they are 
never used by the user/DMVll-command structure. 



BSEL 
BSEL3 
BSEL5 
BSEL7 
BSEL1 1 



7 


6 


5 


4 


3 


2 


1 





7 


6 


5 


4 


3 


2 


1 





RUN 


MTR 
CLR 












MNT 
REQ 








EN 

"B" 




MP 
INTA 


fiP 
INTB 


EN 

"A" 


I 


I 1 


1 1 


NOT 

1 1 


USED 

1 1 


1 1 


l 1 


MNT 
RDY 




"A" 
INT 


"B" 
INT 


Fl 


JNCTIC 

1 1 


)N CO 
I 


DE 

1 



DMV11 MEMORY LOCATION (HIGH BYTE) 
FOR FUNCTIONS 1-5 

H 1 1 1 1 1 1- 



FOR FUNCTIONS 1-5 
H 1 1^ h 



DATA READ OR WRITTEN FOR FUNCTIONS 1 , 2 & 6 or 16 BIT ADDRESS FOR FUNCTIONS 3 & 4 



-I- 



1 

UNUSED 



■4- 



NOT USED 
I 



UPPER ADDRESS BITS 
FOR FUNCTS 3 & 4 
I I I 



15 14 



13 12 11 10 



1 



Figure 4-3 DMV11 Maintenance Loop Command Format 
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Table 4-6 Maintenance Command Functions BSEL2 Bits 0-3 



Octal Code 
Bits 0-3 


Function 





Reserved to avoid unpredictable results. 


1 


Read DMV11 memory location specified by SEL4 (16-bit address specifying a 
byte). SEL6 contains the data read from this location. 


2 


Write DMV11 memory location specified by SEL4. SEL6 contains the data 
written to this location. 


3 


Read 256 bytes of DM VI 1 memory. SEL4 points to the starting DM VI 1 mem- 
ory address from which the information is read. The lower eight bits of this ad- 
dress are ignored. SEL6 and BSEL8 point to the starting LSI-1 1 bus address 
where the information is stored. 


4 


Write 256 bytes of DM VI 1 memory. SEL4 points to the starting DM VI 1 mem- 
ory address to which the information is written. The lower eight bits of this ad- 
dress are ignored. SEL6 and BSEL8 point to the starting LSI-1 1 bus address 
from which the information is read. 


5 


Set the 6502 microprocessor's program counter to the value contained in SEL4. 
This is used to start the microprocessor executing code at the DM V 1 1 memory 
location specified by SEL4. 


6 


Set internal loop and null clock for functional diagnostics. Null clock is in- 
itialized for 56K b/s. 


7 


Set maintenance interrupt flags and clear interrupt disable in processor status. 
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CHAPTER 5 
ASPECTS OF DMV11 
MICROCODE OPERATION 



5.1 INTRODUCTION 

The functionality of the DMV11 results from the microprocessor and its associated microprogram or 
microcode. This chapter discusses the microcode as it relates to: 

• The polling algorithm, 

• Error recording, and 

• The internal data base. 

5.2 DMV11 POLLING ALGORITHM 

In a polling operation the tributaries are in effect asked one by one whether they have anything to 
transmit. To accomplish this, the control station sends a polling message with a unique tributary ad- 
dress down the line. The station which recognizes the address responds with data messages or a positive 
response. 



With DMVlls, polling is based on a priority scheme which is derived automatically and applied dy- 
namically by the microcode. To control polling and data message transmission, the DMV11 uses the 
following information: 



• The tributary's recent poll history, 

• The tributary's user-defined parameters, 

• The tributary's protocol state. 

In regard to protocol state, the multipoint network control station polls all established tributaries that 
are not in the DDCMP halt state. The protocol state of every established tributary is maintained in the 
associated TSS by the control station. When a tributary is eligible for polling, all outstanding transmit 
messages for that tributary are sent as the poll, up to the limit imposed by the maximum transmitted 
message count. If no transmit messages are available for a tributary eligible for polling, the DMV11 
automatically transmits the appropriate DDCMP control message. 



The DMV11 polling algorithm determines which tributary is to be polled next, based on each tributa- 
ry's polling urgency level. The DMV11 polling algorithm employs the user-defined TSS and GSS pol- 
ling parameters as the basis for categorizing tributaries into polling levels. The polling algorithm also 
determines the rate at which polling urgency is increased within each polling level. A tributary's polling 
level is based on its recent response history. This classification mechanism, combined with periodic in- 
crementing of polling urgency, results in the most active tributaries being polled most often. 
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5.2.1 Calculating Polling Urgency 

The polling urgency (priority) of each tributary is periodically calculated when a global timer expires. 
This periodic calculation enables the algorithm to enforce minimum poll intervals for each tributary, 
and to account for competition between tributaries. The minimum poll interval prevents unneeded polls 
from: 

• Delaying other tributaries, 

• Interfering with output traffic, and 

• Causing unnecessary processor overhead. 

The polling urgency of a tributary is calculated as a linear function of time elapsed since the last poll. 
The calculation is truncated when the maximum value of 255 is reached. The three parameters in this 
calculation are: 



1. Q - the initial value of the polling urgency (U); 

2. R - the rate at which Q is to be increased; 

3. DELTA T - the polling algorithm global update interval. 

Figure 5-1 shows the relationship between these three parameters. The appropriate choice of Q and R 
can give a variety of behaviors. For this reason, the choice of these values must be based on the desired 
performance. One method of choosing Q and R is to define the minimum poll time and the time to 
reach maximum poll urgency, and to use these values in the following equations. 



Minimum poll time = 128-Q (DELTA T) 

R 

Time to reach maximum poll urgency = 255-Q (DELTA T) 

R 



DELTA T is the user-defined period of the global timer and its value depends on the line speed. It must 
be smaller than the smallest nonzero minimum poll interval, but no smaller than 200 ms. The poll prior- 
ity is calculated for each tributary and stored in a single byte of the TSS. With every DELTA T, the 
polling urgency byte is updated. The following interpretation is placed on its value. These values are 
represented as base lines on the graph of Figure 5-1. Figure 5-2 shows the relationship of the polling 
urgency to different values of Q and R. 



0-127 Do not poll the tributary. The minimum poll interval has not expired. 

128 Minimum poll interval has expired. The tributary is eligible for polling. 

1 29 - 254 Minimum poll interval is exceeded. The tributary is eligible for polling. The 

higher values indicate increasing priority in the event of competition between 
tributaries. 

255 Maximum poll urgency is reached. Competition between tributaries at this pri- 

ority is round-robin. 



This method of determining values for Q and R is applicable when static behavior is desired. For many 
applications, however, dynamic behavior can improve performance by polling active tributaries at a 
faster rate and with a higher priority than inactive tributaries. 

During each DELTA T time period, the control station polling algorithm updates the urgency of each 
operational tributary by adding the value of R for the appropriate polling state (excluding dead) to the 
urgency value of each tributary. This updating sequence is performed on the TSS data base in the order 
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in which tributaries were originally established at the control station. When the polling algorithm deter- 
mines that the next poll is to be sent, it selects the tributary to be polled by scanning the TSS data base 
(in the original order of tributary establishment), starting at the TSS following the last tributary polled. 
In this process, the tributary having the highest value of U from active, inactive, and unresponsive 
tributaries is selected as the next tributary to be polled. 



TIME TO 
MAXIMUM URGENCY 



255 



>- 
o 

LU 

£ 128 
3 127 



o 



ELIGIBLE FOR 
POLLING 



MINIMUM 
POLLING INTERVAL 



NOT POLLED 



R 



T — I — I — I — I — I — I — I — I I I — I — I — I — | — I — I — I I I I I — | — I — I — I — I — I — I — I I — I — I — I — I — I — I I I 

At A t = 200ms 



-A 



Figure 5-1 Interrelationship Between Polling Parameters Q, R, and DELTA T 



If an urgency of 255 is detected during the process of scanning the TSS data base for the tributary 
having the highest value of U, the scan process is halted and that tributary is immediately selected for 
polling. Once the selected tributary is polled, its urgency reverts to the assigned value of Q for its pol- 
ling level. 



Dead tributaries are polled at a rate determined by the user-defined parameter DEAD T. One dead 
tributary is polled at each expiration of the DEAD T timer, and the scan of dead tributaries is resumed 
from the last dead tributary polled. 
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Figure 5-2 Relationship Between Polling Parameters Q, R, and the Minimum Polling Interval 



The dynamic polling algorithm uses Q and R values based on dynamically modified states. There are 
four of these states: 

1 . Active - The polling algorithm maintains a tributary as active when it responds to polls with 
data messages. 

2. Inactive - The polling state of an active tributary is changed to inactive when it responds to a 
consecutive number of polls with nondata DDCMP messages. The count of consecutive non- 
data messages received from a tributary in the active state is designated by the user-defined 
parameter NDM-INACT (number of no-data messages required to go inactive). 

3. Unresponsive - A tributary currently active or inactive is changed to the unresponsive state 
when it fails to respond in any way to a consecutive number of polls (each poll results in a 
selection timeout). The count of consecutive polls without responses is designated by the 
user-defined parameter TO-UNRESP (number of timeouts to go unresponsive). 

4. Dead - A currently unresponsive tributary which continues to be unresponsive to consecutive 
polls is changed to dead. This occurs when the number of selection interval timeouts desig- 
nated by the user-defined parameter TO-DEAD (number of timeouts to go dead) is exceed- 
ed. Unlike tributaries in the other polling states, dead tributaries are always polled on a 
round-robin basis with the period between polls being determined by the user-defined global 
parameter DEAD T (dead timer). 
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When specifying the parameters controlling polling levels, the user has the option of accepting the 
defaults (see Table 4-2 and 4-3), or selecting specific values in place of these defaults. The user pro- 
gram can set the polling state of a tributary to any state at any time by issuing a latch polling state 
control command. The polling state imposed by a control command remains in effect, irrespective of 
tributary performance, until polling control is handed back to the polling algorithm by the user pro- 
gram. This is done by issuing an unlatch polling state control command. 

Figure 5-3 shows the relationship of the the default values of Q and R for the active, inactive, and 
unresponsive polling states. 




Figure 5-3 Relationship Between the Default Values for Q and R for the Three 
Polling Activity Levels 
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Each tributary has Q and R values defined by the user for the active, inactive, and unresponsive polling 
states. This allows dynamic modification of the behavior of the polling algorithm. The basic mechanics 
of the polling algorithm are: 



• If a tributary always responds to a poll with data, it remains in the active state. The polling 
urgency in this case is calculated using the Q and R values specified for the active state. 

• If a tributary responds to a user-defined number of consecutive polls with no data messages 
(ACKs only), polling is changed to inactive. The polling urgency is then calculated based on 
the Q and R values defined for the inactive state. 

• If a tributary in either the active or inactive states fails to respond (times out) to a pre- 
determined number of consecutive polls, the polling state is changed to unresponsive. The Q 
and R values defined for the unresponsive state are used to calculate the polling urgency. 

• If a tributary in the unresponsive state fails to respond to a predetermined number of con- 
secutive polls, the polling state is changed to dead. The user is notified of this transition by a 
control response. Polling dead tributaries is very time-consuming because it usually requires 
a timeout. Therefore, dead tributaries are not polled on a priority basis. Instead, a global poll 
interval is defined for dead tributaries. Each time this timer expires, a single dead tributary 
is polled. If at any time a dead tributary responds to a poll with a data message or ACK, its 
state is changed to active. 



NOTE 

A tributary (not in the active polling state) is auto- 
matically returned to the active state when it re- 
sponds to a poll with a valid data message. It also 
becomes active when the user program allocates a 
transmit buffer to it. 



Figure 5-4 is a state diagram describing the transitions between polling states. The actual transitions are 
dependent on the particular polling parameters. 

The user may control sending of all polls by defining a poll delay interval that must expire before a poll 
can be sent. 

The program-selectable parameters which pertain to polling are included in Table 4-2. These parame- 
ters are set by the user with a write TSS command. 



5.2.2 Criteria for Determining Polling Parameters 

Although there are no absolute rules for determining polling parameters, there are general guidelines 
for deriving them. These guidelines are presented in sections 5.2.2.1 through 5.2.2.4. 



5.2.2.1 Determining a Value for DELTA T - For most multipoint network applications, the default 
value of 200 ms for DELTA T is adequate. The default value of 200 ms is the smallest permissible 
value for DELTA T and represents the actual time required for the microcode to update the urgencies 
of 1 2 tributaries. However, in specific cases a higher value of DELTA T might be recommended. An 
example of this is a network formed by low traffic devices. 
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NOTE 

The minimum polling interval defines the time re- 
quired for a tributary to reach the urgency threshold 
value of 128. This is the minimum time required to 
be eligible for polling. The maximum polling interval 
cannot be determined. This is because it is a function 
of line speed, message traffic, the number of tribu- 
taries in a network, and the polling states of those 
tributaries. These variables make it impossible to 
predict the time at which any tributary in a network 
is polled. 
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Figure 5-4 State Diagram of Polling State Transitions 



5.2.2.2 Determining Values for Q and R - For a given value of DELTA T, the minimum polling inter- 
val is a function of the user-defined parameters Q and R. For example, if a minimum polling interval of 
3.2 seconds is desired for a tributary (assuming DELTA T = 200 ms), the parameters Q = 0, and R = 
8 satisfy this requirement. With these values of Q and R, the time to reach maximum polling urgency is 
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6.375 seconds (see Figure 5-2). Notice that if Q = 64 and R = 4, the minimum polling interval re- 
mains at 3.2 seconds but the maximum polling urgency increases to 9.55 seconds. 

NOTE 

Reaching maximum polling urgency represents max- 
imum eligibility for polling, but does not guarantee 
that a tributary will be polled, 

Figure 5-3 graphs the relationship between the default values of Q and R for each of the three polling 
states. When all tributaries in a network have the default value for Q and R, and all tributaries are in 
the active polling state, the manner of polling is round-robin. 

5.2.2.3 Determining a Value for Poll Delay - The user-defined global parameter poll delay imposes a 
fixed delay between control station polls. This provides a mechanism for regulating message traffic 
without changing the values of Q and R for individual tributaries. During this delay, transmission from 
the control station to tributaries is halted for the interval defined by the poll delay timer. This interval 
begins when the tributary just polled deselects itself. 

The ability to regulate message traffic through a single parameter is valuable in multipoint networks. 
This is especially true where DM VI Is are configured together with slower character interrupt commu- 
nication devices such as DUP1 Is. The value selected for poll delay in these circumstances is a function 
of the character handling rates of the non-DMVll devices. 

In remote multipoint networks where the distance between the control station and tributaries varies 
significantly, there is a greater chance of transmit and receive errors. This is due to the difference in 
communication line settling time in such a network. In such instances, the settling time for the most 
distant tributary station should be used for determining a value for poll delay. 

For DM VI 1 -implemented high-speed local networks, this parameter is unnecessary. The default value 
(zero) for poll delay is used in these networks. 

5.2.2.4 Determining a Value for DEAD T - This global parameter establishes the rate at which dead 
tributaries are polled. Dead tributaries are polled on a round-robin basis, with one tributary polled at 
each expiration of the dead tributary timer. 

Polling dead tributaries can significantly impact network line utilization. The shorter the period of this 
timer - the greater the impact. For a given value of DEAD T, the impact decreases as system line 
speed increases. When determining a value for this parameter, the primary goal is to minimize the im- 
pact on network line utilization. 

The value for DEAD T should be based on the period of the selection interval timer for the specific 
application. For example, if the period of the dead tributary timer and the selection interval timer are 
equal, only dead tributaries are polled. For most system applications, the period of the dead tributary 
should be from three to ten times greater than that of the selection interval timer. This of course de- 
pends on line speed. The default value for DEAD T is ten seconds. This is about three times the default 
value for the selection interval timer. 

5.3 ERROR COUNTERS 

In multipoint networks many tributaries tie to the same transmission line. Because of this, it is more 
difficult to determine which link, if any, is causing errors. To aid in troubleshooting, the DMV11 main- 
tains extensive error counters. Every DMV11 in the network (the control station and each tributary) 
uses error counters to record errors. This allows user programs at any DM VI 1 in the network to deter- 
mine overall error rates and to detect a malfunctioning link. 
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Data link errors are indicated to the DMV11 by DDCMP negative acknowledge messages (NAKs). 
Each NAK contains an address field and a reason code that identifies the source and reason for the 
NAK. In general, when an error is detected in an incoming message, the station that receives the mes- 
sage sends a NAK to the station that sent the message. By recording NAKs sent and NAKs received, 
each point or tributary in the network is able to compile statistics on the condition of the link estab- 
lished between the two stations. DDCMP error recording has been designed so that even if one of the 
stations on the link cannot record errors, the other station may be used to record errors for all commu- 
nications in both directions on the link. 

There are three main categories of error counters used by the DMV11; data link counters, station 
counters, and threshold counters. Data link counters and threshold counters are maintained for each 
tributary/control station pair on a physical link. These counters are located in the tributary status slots 
of the data memory (Figure 5-5). Station counters are maintained for the physical link as a whole, and 
are located in the global status slots of the data memory (Figure 5-6). Unless otherwise stated, all 
counters increment to a maximum value and hold that value until cleared. 

5.3.1 Data Link Error Counters 

Data link counters are of two types; cumulative and background. The cumulative counters are 8-bit 
registers which latch at 255. The background counters are 16-bit registers which latch at 65535. The 
cumulative data link counters record and total all occurrences of an error and group them into the fol- 
lowing categories. 

• Data errors outbound, 

• Data errors inbound, 

• Local reply timeouts, 

• Remote reply timeouts, 

• Local buffer errors, 

• Remote buffer errors, 

• Selection timeouts. 

Background data link counters are used to provide a statistical base for the cumulative error counters 
and therefore record: 

• The number of data messages transmitted, 

• The number of data messages received, and 

• The number of selection intervals. 

A point-to-point station maintains a single set of data link counters. Multipoint stations (control and 
tributary) maintain a separate set of data link counters for each established tributary. Data link 
counters are cleared by: 

• A master clear of the DM VI 1, 

• A control command to establish the tributary, or 

• A user-issued control command to read and clear the TSS error counters. 

5.3.1.1 Data Errors Outbound - This 8-bit group counter records NAKs received for data errors oc- 
curring on the communications channel outbound from this station. There are three types of outbound 
errors for which this counter records NAKs received; header blockcheck (OHBCC), data field block- 
check (ODBCC), and reply response (OREP). Three separate flag bits indicate which type of outbound 
error is being counted. 

• OHBCC (outbound header blockcheck) is set when a NAK with a reason code of one is re- 
ceived for a header block-check error for either data or control messages. 
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ODBCC (outbound data field blockcheck) is set when a NAK with a reason code of two is 
received for a data field block-check error. 

OREP (outbound reply response) is set when a NAK with a reason code of three is received 
for a reply message response. 
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Figure 5-5 Data Link and Threshold Error Counters 
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Figure 5-6 Station Error Counters 



5.3.1.2 Data Errors Inbound - This 8-bit group counter records occurrences which normally result 
from data errors on the communications channel inbound to this station. Three separate bits indicate 
specific error types associated with this counter. 

• IHBCC (inbound header blockcheck) is set when messages having header-block check errors 
are received. When this error occurs, point-to-point stations and multipoint control stations 
send a NAK with a reason code of one. A multipoint control station records this error for the 
selected tributary regardless of the address field in the received message. A multipoint tri- 
butary records this error only if the address field matches its station address. 

• IDBCC (inbound data field blockcheck) is set when NAKs with a reason code of two are to 
be sent for data field block-check errors. 

• I REP (inbound reply response) is set when NAKs with a reason code of three are to be sent 
for a reply response. 

5.3.1.3 Local Reply Timeouts - This 8-bit counter records occurrences which result from: 

• The loss of communications between two stations while the one recording this error has data 
to transmit, or 

• The choice of an inappropriate value for the reply timer. 
Specifically, this error counter records the sending of a REP message. 

5.3.1.4 Remote Reply Timeouts - This 8-bit counter records occurrences which result from: 

• The loss of communications between two stations while the remote station has data to trans- 
mit, or 

• The choice of an inappropriate value for the remote station reply timer. 

Specifically, this counter records ACKs sent in response to a REP. The remote station sent a REP 
because it received no acknowledgement for messages it previously sent. The local station received 
those messages, but the remote station never received the acknowledgement. 
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5.3.1.5 Local Buffer Errors - This 8-bit counter records the fact that the user program at the station 
recording the error failed to properly allocate receive buffers to data messages from the remote station. 
Two separate bits indicate the specific errors associated with this counter. 

• LBTU (local buffer temporarily unavailable) is set when a buffer is temporarily unavailable. 
This condition indicates that a NAK with a reason code of eight is to be sent. 

• LBTS (local buffer too small) is set when a local buffer is too small for the incoming mes- 
sage. This condition indicates that a NAK with a reason code of 1 6 is to be sent. 

5.3.1.6 Remote Buffer Errors - This 8-bit counter records the fact that the user program at the remote 
station failed to properly allocate receive buffers to data messages from the station recording the error. 
Two separate bits indicate the specific errors associated with this counter. 

• RBTU (remote receive buffer temporarily unavailable) is set when a NAK with a reason 
code of eight is received. 

• RBTS (remote receive buffer too small) is set when a NAK with a reason code of 16 is re- 
ceived. 

5.3.1.7 Selection Timeouts - This 8-bit counter records the occurrences which result from: 

• Loss of communications with a remote station, 

• Data errors on the communications channel to or from the remote station, and 

• The choice of an inappropriate value for this station's select timer. 

This counter is used only by half-duplex point-to-point or multipoint control stations. Two separate bits 
indicate the specific errors associated with this counter. 

• NRTS (no reply to select) is used to record selection intervals in which no transmission is 
received from the tributary, and no attempt to transmit is detected. Specifically, it records 
the expiration of the select timer without the receipt of a valid control message or header, or 
the detection of an attempted transmission. 

• IRTS (incomplete reply to select) is used to record selection intervals which were not proper- 
ly terminated. Specifically, it records the expiration of the select timer preceded by receipt 
of a valid control message, receipt of a valid header, or detection of an attempted transmis- 
sion. An attempted transmission is indicated by: 

- The presence of a carrier signal, 

The receipt of a DDCMP synchronization sequence, and 

- The receipt of an SOH, ENQ, or DLE. 

5.3.1.8 Data Messages Transmitted - This 16-bit counter records messages transmitted by this station, 
and latches at a count of 65535. It can be used as a statistical base when evaluating data errors out- 
bound, local reply timeouts, and remote buffer errors. Messages sent as a result of retransmission are 
not included in this count. 

5.3.1.9 Data Messages Received - This 16-bit counter records messages received by this station, and 
latches at a count of 65535. It can be used as a statistical base when evaluating data errors inbound, 
remote reply timeouts, and local buffer errors. Messages received out of sequence or in error are not 
included in this count. 
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5.3.1.10 Selection Intervals - This 16-bit counter records the number of times this station selects the 
other station. It also latches at a count of 65535. Specifically, it records the number of messages trans- 
mitted with the select flag on. It is only used by half-duplex point-to-point and multipoint control sta- 
tions. It can be used as a statistical base when evaluating the number of selection timeouts. 

5.3.2 Station Error Counters 

Station counters are 8-bit counters which latch at 255 and record unusual occurrences. These occur- 
rences may be the result of: 

• A hardware or software fault at this station, 

• A hardware or software fault at a remote station, or 

• A data error on the communications channels undetected by the header block-check field. 
A single set of these counters is used for all tributaries on a multipoint link. 

There are four types of station counters: 

1 . Remote station errors, 

2. Local station errors, 

3. Global header block-check errors, and 

4. Maintenance data field block-check errors. 

Station counters are cleared by: 

• A master clear of the DMV11, or 

• A user-issued control command to read and clear the GSS error counters. 

5.3.2.1 Remote Station Errors - This 8-bit counter records occurrences caused by a fault in a remote 
station or by an undetected data error on the channel inbound to this station. Four separate bits indicate 
the specific errors associated with this error counter. 

• ROVRN (remote receive overrun) is set when a NAK with a reason code of nine is received 
for a receive overrun. 

• RMHFE (remote message header format errors) is set when a message is received which has 
a header format error. This condition indicates that a NAK with a reason code of 17 is to be 
sent. 

• RSEL (remote selection address error) is set when a multipoint control station receives a 
message containing an address field which does not match the address of the currently se- 
lected tributary. RSEL is a flag used only by multipoint control stations. 

• RSTR (remote streaming tributaries) is set by either one of two events: 1) an implementa- 
tion-dependent maximum transmission interval is exceeded without releasing the channel 
(babbling tributary), or 2) the channel is not released following the end of a selection interval 
(streaming tributary). 

5.3.2.2 Local Station Errors - This 8-bit counter records occurrences caused by a fault in a local sta- 
tion or by an undetected data error on the channel outbound from this station. Four separate bits in- 
dicate the specific errors associated with this error counter. 

• LOVRN (local receive overrun, NAK sent) is set for local station receive overruns. This con- 
dition indicates a NAK with a reason code of nine is to be sent. 
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• LOVR (local receive overrun, NAK not sent) is set by a receive overrun when a NAK is not 
sent. For a multipoint tributary, this happens if an overrun occurs while receiving a header. 
For other stations, this occurs when the station is not in the DDCMP run state. 

• LUNDR (local transmit underruns) is set when a transmit underrun occurs. 

• LMHFE (local message header format error) is set when a NAK with a reason code of 17 is 
received to indicate a message with a header format error was sent by this station. 

5.3.2.3 Global Header Block-Check Errors - This 8-bit counter records the occurrence of header 
block-check errors that are not recorded on a per tributary basis. Specifically, it counts header block- 
check errors for maintenance messages and for messages to tributaries where the address field does not 
match the station address. 

5.3.2.4 Maintenance Data Field Block-Check Errors - This 8-bit counter records the occurrence of 
data field block-check errors for maintenance messages. 

5.3.3 Threshold Error Counters 

Threshold error counters are used to determine if a persistent fault exists. A persistent fault is one 
which occurs seven consecutive times. Whenever a threshold counter reaches its maximum value (7), 
the user program is notified by a control response. 

In the DDCMP run state, threshold counters are cleared when the user is notified. In this way the user 
is continually informed of a persistent fault. In the DDCMP ISTRT and ASTRT states, threshold 
counters are not cleared when the user is notified. In this way the user is not continually informed of an 
inoperative remote station. 

A point-to-point station maintains a single set of threshold counters. A multipoint control station main- 
tains a separate set for each tributary. A multipoint tributary maintains a single set unless it supports 
multiple tributary addresses in which case it maintains a single set for each established tributary ad- 
dress. 

There are three types of threshold error counters: transmit, receive, and selection. 

5.3.3.1 Transmit Threshold Errors - This 3-bit counter is incremented (if less than seven) in the fol- 
lowing instances. 

1. The DMV1 1 is in the ISTRT state when a STRT message is sent, 

2. The DM VI 1 is in the ASTRT state when a STACK message is sent, or 

3. The DMV1 1 is in the run state and a NAK with a reason code other than three (REP re- 
sponse) is received, or when sending a REP message. 

The transmit threshold error counter is cleared: 

• Upon entering the ISTRT, ASTRT, or run states. 

• While in the run state one of the following occurs: 

- A transmit threshold error is reported, 

A NAK, ACK, or data message is received acknowledging a new message, or 

- A NAK, ACK, or data message is received when no messages are outstanding. 
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5.3.3.2 Receive Threshold Errors - This 3-bit counter is incremented (if less than seven) when a NAK 
with one of the following reason codes is sent. 



Reason Code Description 

1 Header block-check error. 

2 Data field block-check error. 

3 REP response. 

8 Buffer temporarily unavailable. 

9 Receive overrun. 

16 Message header format error. 



This counter is cleared when: 

• Entering the ISTRT, ASTRT, or run states, 

• A control message with a correct header blockcheck is received without a header format er- 
ror, 

• A data message with correct header and data field blockchecks is received without a header 
format error, or 

• In the run state, a receive threshold error is reported. 

5.3.3.3 Selection Threshold Errors - This 3-bit counter is only used by multipoint control stations and 
half-duplex point-to-point stations. It is incremented (if less than seven) when a selection timeout oc- 
curs. 

It is cleared upon receipt of a message with the select bit set, or while in the run state and a selection 
threshold error is reported. 

5.4 DMV11 MICROCODE INTERNAL DATA BASE OVERVIEW 

Functionally, the DMV11 internal data base provides the mechanism for managing: 

• The assignment and completion of transmit and receive buffers, 

• The queuing of DMV11 responses, 

• The assignment of TSS structures to established tributaries for the storage and maintenance 
of tributary and global status information. 

A map of this data base is shown in Figure 5-7. The data base is implemented by three basic structures: 

• Linked lists, 

• Slot mapping table, 

• TSS and GSS structures. 

Each of these are described below in terms of organization and function. 
5.4.1 Linked Lists 

A linked list is an open-ended data list made up of fixed-length blocks linked by pointers. Each of these 
blocks (link blocks), contain seven bytes of data and a one byte pointer to the next link block in the list. 
The pointer in the last block in the list is a terminator value. Figures 5-8 and 5-9 illustrate the standard 
format for DMV11 linked-list structures. 
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Figure 5-7 Data Memory Map 



A DMV1 1 linked list is made up of five kinds of linked lists. 
1 



2. 
3. 

4. 
5. 



The free linked list - A list of empty link blocks used by the microcode to form the remaining 
kinds of linked lists. 

The response linked list - A queue of responses for posting to the user program. 

The common buffer pool linked list - A list of the accessing information for each receive 
buffer assigned to the common pool. There is one link block for each assigned buffer. 

Receive buffer linked list - A list of receive buffer accessing information. One of these is 
maintained by the microcode for each established tributary having private receive buffers 
assigned. There is one link block for each buffer. 

Transmit buffer linked list - A list of transmit buffer accessing information. One of these is 
maintained by the microcode for each established tributary having transmit buffers assigned. 
There is one linked list for each buffer. 



5.4.1.1 The Free Linked List - The free linked list from which all other linked lists draw link blocks, is 
maintained in the lower section of data memory called the buffer and output queue (BOQ) (Figure 5- 
7). These 832 bytes translate into a total of 104 link blocks available for use by the operational linked 
lists. In this way, the free linked list functions as a finite resource for the operational linked lists. 
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Figure 5-8 DMV11 Linked List Structure Format 

As previously stated, a linked list is equipped with two list pointers; one that points to the start of the 
list and one that points to the end of the list. When a link block is removed from the free linked list, the 
start of the list pointer is changed to point to the next available link block in the free linked list. When a 
link block is completed by one of the operational linked lists, it is added to the end of the free linked list 
and its internal pointer is set to the terminator value of 377 octal. In addition, the internal pointer in the 
next to last link block is changed from 377 octal to the address of the link block just added. The start- 
and end-of-list pointers for the free linked list are maintained in the station GSS. 
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Link blocks are removed from the free linked list and added to the receive, transmit, or common pool 
buffer linked lists when the user program issues control or buffer address/character count commands 
for that purpose. Similarly, link blocks are removed from the free linked list and added to the response 
linked list when the DM VI 1 microcode posts a response to the user program. If the last link block is 
removed from the free linked list, the start of the list pointer is set to the terminator value of 377 octal 
to indicate there are no more link blocks available. In this event, the next request for a link block gener- 
ates the fatal error QUEUE OVERFLOW. For this reason, the buffer allocation strategy for a user 
program must be designed to assure an adequate number of link blocks. 
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Figure 5-9 Standard Link Block 



5.4.1.2 The Response Linked List - This linked list functions as a queue of buffer disposition, control, 
and information responses to be posted to the user program. The format of the link block for each of 
these three responses is shown in Figure 5-8. When preparing a link to convey a control or information 
response, the microcode clears all unused bit positions in the link block to zero. However, link blocks 
restored to the free linked list remain unchanged. 

The start-of-list and end-of-list pointers for the response linked list are maintained in the station GSS. 

5.4.1.3 Buffer Linked Lists - A buffer linked list is provided for each type of message buffer allocated 
by a user program. These are: 

• Common pool receive buffers, 

• Private receive buffers, and 

• Transmit buffers. 

Each link block in a buffer linked list provides the location and size of a buffer in main memory. 

The Common Buffer Pool Linked List - This linked list provides a queue of receive buffers available to 
all established tributaries according to the quota assigned to each tributary. 

Common pool buffers are assigned through the buffer address/character count command, and enabled 
with tributary quota assignments through the control command (see Section 3.3.3). The start-of-list and 
end-of-list pointers for this linked list are maintained in the station GSS. 

Receive Buffer Linked List - This linked list serves as a queue of private receive buffers. One list is 
maintained for each tributary established at a multipoint station. For point-to-point stations, one list is 
maintained at each station. The start- and end-of-list pointers for each receive buffer linked list are 
maintained in the associated tributary's (or station's) TSS. 
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Transmit Buffer Linked List - This list functions as a queue of transmit buffers. One list is maintained 
for each tributary established at a multipoint station. For point-to-point stations, one list is maintained 
at each station. The start- and end-of-list pointers for each transmit buffer linked list are maintained in 
the associated tributary's (or station's) TSS. 

A unique feature of this link block is the message number field. When a message is transmitted from a 
buffer, the header of that message contains the DDCMP message number (in the message number 
field). The microcode uses this field to locate the buffer for a message that has been NAKed after 
transmission and, therefore, must be retransmitted. 

5.4.2 Slot Mapping Table 

Under DDCMP, the 8-bit message header address field permits a maximum of 255 unique tributary 
addresses in a multipoint network. However, the DMV11 microcode limits the number of established 
tributaries to 12. In order to implement DDCMP, a tributary in a DMV 11 -based multipoint network 
can have a TSS address in the range of 1 to 255. However, only 12 of these tributaries may be estab- 
lished at any one time. 

TSS addresses are assigned at both control and tributary stations through the slot mapping table 
(SMT). As shown in Figure 5-7, this table occupies 256 locations in DMV1 1 data memory; one location 
for each of the 255 possible tributary addresses, and one location to address the GSS. 

The function of the SMT is to map an 8-bit tributary address into one of the 12 available TSS struc- 
tures. When a tributary is deleted, its TSS and SMT entry is released for reassignment. When 12 tribu- 
taries are established and an attempt is made to establish a 1 3th, a procedural error is posted to the user 
program. 

5.4.3 TSS and GSS Structures 

The TSS and GSS structures occupy separate sections of data memory. The GSS is a single 64-byte 
section while the TSS structure consists of twelve 64-byte sections. 

5.4.3.1 The Global Status Slot (GSS) - Functionally, the GSS is used to: 

• Maintain control and status information specific to the operation of the microcode, 

• Record event counts and error conditions that are global in nature, and 

• Store global parameters. 

The majority of the GSS is devoted to microcode control and status information. A detailed map of the 
GSS is shown in Figure 5-10. 

Access to the GSS is accomplished on word boundaries. A user program can read any GSS location 
through the control command. The content of the addressed location is transferred to the user program 
through an information response. A user program can read and clear only GSS station error counters. 
The four global parameters (locations 34 through 37) are written by the user program through the con- 
trol command. 

5.4.3.2 Tributary Status Slots (TSS) - A TSS contains four general categories of tributary informa- 
tion (Figure 5-11): 

1. Protocol and tributary status, 

2. Error and statistical counters, 

3. Message exchange variables, and 

4. Polling parameters. 
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Protocol and Tributary Status - This category includes information on the tributary's protocol state, its 
status with relation to the logical communications line, its protocol status, and its polling status. Tri- 
butary polling status is maintained only at a multipoint network control station. Although this informa- 
tion is only pertinent to, and used by the DMV11 microcode, it can be read by a user program. 

Error and Statistical Counters - These counters provide the user program with a wide range of error 
counts, and a set of statistical counts that permit analysis of the meaning of specific error counts. These 
counters can be read and cleared by the user program. The function of each of these counters is de- 
scribed in detail in Section 5.3. 

Message Exchange Variables - This category includes a range of variables used by the microcode to 
control the transmission and reception of message data. This includes the common buffer pool quota 
assigned by the user program. 

A group of timers is also included in the message exchange variables. These timers can be preset to a 
specific timeout value by the user program, and directly concern message traffic transferred on the 
logical link by the associated tributary. These timers are referred to as: 

• Transmit delay timer, 

• Selection interval timer,* 

• Maximum transmitted message count, 

• Babbling tributary timer. 

The link management functions performed by these timers is detailed in Chapter 4. 

Polling Parameters - These parameters are user-defined values that are used by the polling algorithm 
to conduct dynamic polling activity in multipoint networks. The functions performed by the DMV11 
polling algorithm, and the criteria for determining the values for each parameter, are discussed in detail 
in Section 5.2. 



*A timeout value for the selection interval timer is maintained in each tributary's TSS, but the actual timer is maintained in 
the GSS. 
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CHAPTER 6 
TECHNICAL DESCRIPTION 



6.1 INTRODUCTION 

This chapter provides a block diagram functional description of the DMV11. 

The DMV11 is basically a 6502 microprocessor with interfaces to the LSI-11 bus and the outside 
world. The 6502 is supported with 16K bytes of ROM and 2K bytes of RAM. All I/O is memory map- 
ped to the 6502 data bus. The LSI-1 1 interface is made up of three areas: 

1. NPR circuitry - Full 16-bit direct memory access is allowed on data transferred in and out. 
Independant address registers are provided for the in and out NPR addresses. 

2. CSRs - Eight 16-bit CSRs are mapped into the on-board RAM. Any time the LSI-11 bus 
accesses these registers, the 6502 is halted, the on-board 8-bit RAM is demultiplexed to 16 
bits, and 16-bit data is read from or written to the RAM. 

3. Interrupt circuitry - The 6502 can cause interrupts to the LSI-1 1 bus if enabled by the CPU. 
Two separate bits allow two levels of interrupt to be initiated. 

The outside world interface is handled by a USYRT using a serial transmit and a serial receive line. 
The USYRT interfaces directly to the 6502 data bus; activated and monitored by data and status trans- 
fers using a predefined address space. 

The remaining circuitry which makes up the DM VI 1 is used to support the USYRT, the LSI-1 1 inter- 
face, the DDCMP protocol, and the modem interfaces. 

6.2 LOGIC DESCRIPTION 

For discussion purposes, the DMV11 logic is divided into the blocks shown in Figure 6-1. The circuitry 
and functions represented by each of these blocks is described in Sections 6.2.1 through 6.2.7. 

6.2.1 Control and Address Decoder 

This block contains the 6502 microprocessor, timing circuits, 6502 data and address interfaces, and 
address decoders. 

6.2.1.1 The 6502 Microprocessor - The 6502 microprocessor is a 40-pin microprocessor with a full 16- 
bit address bus, an 8-bit bidirectional data bus, and two interrupts. 

The 6502 is organized around two primary buses: the address bus and the data bus. The address bus is 
used to transfer the address generated by the microprocessor to the address inputs of memory. The data 
bus consists of an 8-bit bidirectional data path. All data and instructions are transmitted on this bus. 

The 6502 provides a sync-signal to indicate when it is fetching operation code from program memory. 

The timing of all data transfers is controlled by a two-phase clock (two nonoverlapping square waves) 
referred to as Phase 1 and Phase 2. The address lines and read/write line stabilize during Phase 1 and 
data is transferred during Phase 2. 
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Figure 6-1 DMV11 Block Diagram 



6.2.1.2 Timing Circuits - The source for all the timing signals necessary for the DM VI 1 is a 20 MHz 
crystal. The timing signals produced from this source are: 

• The 6502 microprocessor clock - This clock rate is 1.67 MHz and is generated by dividing 
the 20 MHz clock by 6 and then by 2. The 1.67 clock has a duty cycle of 50% ±2 ns. 

• The integral modem receiver 20 times clock - This is a 1.11 MHz clock (20 times 56 KHz 
receive clock rate) which is generated by dividing the 20 MHz clock by 9 and then by 2. 

• The integral modem 2 times clock - This is a 111 KHz clock which is generated by dividing 
the 1.11 MHz clock by 10. 

ROM timing is provided for strobing the 8K by eight ROMS. This signal is produced by delaying the 
Phase 2 signal from the 6502 by approximately 160 ns. This allows enough time for the address to 
stablize at the ROMs before strobe time. 



6.2.1.3 6502 Data and Address Interface - This circuit consists of buffers for the address and data 
outputs of the 6502. The buffers have .5 mV low-level inputs so that they are compatible with the 6502 
driving requirements. 
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6.2.1.4 Address Decoders - Addresses for the address bus come from two sources: 1) the 6502 for 
normal microcode execution, and 2) the LSI-11 bus for accessing the CSRs. Accessing the CSRs has 
priority over the 6502 addressing requirements. CSRs are in RAM and are accessed by the CPU 
through the LSI bus interface. 

Decoding of the address bus is accomplished by three separate circuits: 

1 . Block address decoder - A programmable array logic (PAL) is used to decode the ROM, 
I/O, and RAM blocks; and to demultiplex the RAM to 16-bit words when CSRs are ac- 
cessed by the LSI-1 1 bus. 



I/O decoder - This decoder breaks a part of the I/O page up into eight 256-byte sections 
when the block address decoder selects I/O. No attempt is made to decode to a specific ad- 
dress within a section. Thus, multiple addresses within a given section decode the same de- 
vice. 

NPR current address decoder - This circuit decodes to a specific address in the RAM ad- 
dress space. Thus, the NPR address registers are mapped directly from RAM. They reflect 
the contents of the NPR address locations assigned in RAM (Figure 6-2). 
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Figure 6-2 Control and Address Decoder 



6.2.2 I/O Data Bus 

This block contains the USYRT, USYRT control, and line interface control. See Figure 6-3. 

6.2.2.1 USYRT - The USYRT is an LSI subsystem for synchronous communications. It provides the 
necessary logic support by way of parameter registers for DDCMP. Within this discipline a wide range 
of support such as programmable error detection, character recognition, complete serialization, deseria- 
lization, and buffering of data is provided. 

6.2.2.2 USYRT Control - This circuit consists of a 74LS245 data transceiver, a 74LS373 tristate in- 
put data latch, a 74LS244 tristate output data buffer, a 74LS373 tristate address latch, and three 
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74LS74 controlling flip-flops and associated gates. For discussion, the operation of the USYRT control 
logic is divided into write and read operations. See Figure 6-4. 

Write - The 6502 asserts the address, selects the USYRT, and generates the write signal approximately 
140 ns after Phase 1 high is asserted. The data is available from the 6502 approximately 115 ns after 
Phase 2 high is asserted. The USYRT on the other hand, requires data 50 ns prior to the assertion of 
data port enable (DPENA). To achieve the necessary timing relationship, the address and data are 
latched into buffers and strobed into the USYRT by the controlling flip-flops which are clocked by 
signals generated from Phase 1 and Phase 2 timing. Phase 2 is used to gate DPENA to guarantee the 
USYRT minimum requirement of 250 ns for DPENA. 

Read - Again the 6502 asserts the address and selects the USYRT as in a write cycle. The USYRT is 
strobed by the controlling flip-flops and data is made available from the USYRT. In a read operation, 
the address select lines must be held for 30 ns after DPENA (the 6502 does not guarantee this). There- 
fore, the address is latched when Phase 2 high is asserted. 
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6.2.2.3 Line Interface Control - The line interface control section of logic can be broken into two sub- 
sections: 1) switch logic, and 2) programmable interface adapter. 

1. Switch logic - This section consists of two sets of switches and their associated buffers. One 
set of switches has its configuration latched into its buffer at boot time. The configuration of 
the other set of switches is latched at DDCMP interface selection time. 

2. Programmable interface adapter (also referred to as VIA) - This circuit consists of a 6522 
chip and is used to control and monitor the various interface signals to the modem interface 
logic. 

Referring to the 6522, the PB section and bit of the PA section are used as an output register only. 
Bits one through seven of the PA section are used as an input register. CA1 and CA2 are used to mon- 
itor, by way of the 6502 interrupt, modem ready high and clear to send high. PB7 is used to generate 
modem clocks when self-testing with loopback connectors. CB1 is used to produce eight clock pulses at 
a time when instructed to do so by the 6502 microcode. These clock pulses are used to flush the US- 
YRT receiver of data after carrier drops. 



6.2.3 DMV11 Memory 

This block may be divided into three sections as follows. 

1. ROM control storage, 

2. RAM, 

3. NPR in/out registers. 



6.2.3.1 ROM Control Storage - ROMS are used for storing operation codes for the 6502 micro- 
processor. 

In order to provide the most immediate access to data for the 6502, 200 ns ROMs are used and the 
ROM clock is continuously applied to the chip enable (CE) pin of the ROM. 74S241 buffers are used 
on the output so that no more than 9 ns additional delay is introduced. 



6.2.3.2 RAM - This is the data memory for the DMV11. It is organized functionally as shown in 
Figure 6-5. The hardware organizes the RAM into even and odd sections for the sole purpose of having 
16-bit CSRs. When CSRs are accessed from the LSI-11 bus, even, odd, or both sections of the RAM 
are enabled. Two 74LS245 transceivers are used to enable and direct data to and from the LSI-1 1 bus. 
The other two 74LS245 transceivers are used for drive buffering and to disable the RAM from the 8-bit 
microprocessor data bus when the CSRs are accessed by the LSI-1 1 bus. The microprocessor is halted 
when the CSRs are accessed by the LSI-1 1 bus. 



6.2.3.3 NPR In/Out Registers - This circuitry consists of two 16-bit registers (one for address in, and 
one for address out), and two 16-bit registers (one for data in, and one for data out). Extended address 
capabilities are included in two scratchpad registers which are four words deep by four bits wide. 

The microprocessor loads the appropriate NPR address register (in or out) to set up the address for an 
NPR data transfer. This address is then enabled onto the LSI-1 1 bus during the address enable cycle. 

During a read cycle, the data-in register is loaded from the LSI-1 1 bus and read by the 6502. During a 
write cycle, the data-out register is loaded by the 6502 and read by the LSI-1 1 bus. 
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6.2.4 LSI-11 Bus Interface 

The circuitry in this block interfaces the LSI-11 bus to the 6502 microprocessor (see Figure 6-6). It 
consists primarily of the: 



• LSI-11 bus DAL interface, 

• CSR controller, 

• Interrupt controller, and 

• NPR controller. 



6.2.4.1 LSI-11 Bus DAL Interface - This circuit consists of four DC005 chips which interface the 
LSI-11 data and address lines to the DMVT1. The device address of the DMV11, which may be any- 
where in the I/O page, and its associated vector address, is selected by switches on the input to the 
DC005 chips. 



The DC005s are initially in the receive mode (receiving from the LSI-11 bus) in anticipation of an 
address match from the LSI-1 1 bus. When a match occurs, the collector-ored match lines go high and 
enable the CSR control circuit. In addition to detecting an address match, the DC005s in the receive 
mode pass address or data to the DAL lines. In the transmit mode, the DC005s pass data from the 
DAL lines to the LSI-1 1 bus. 
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Figure 6-6 LSI-1 1 Bus Interface 



6.2.4.2 CSR Controller - This circuit consists of a DC004 which: 

• Supplies outputs which indicate when CSRs are selected. CSRs are decoded when the enable 
pin is asserted high and BYSNC strobes on its negative edge. 

• Supplies outputs indicating when a word of data is to be placed on the LSI-1 1 bus, or when a 
byte or word of data is to be read from the bus. Byte operations are controlled by the OUT 
HB and OUT LB signals. 

• Asserts BRPLY approximately 30 ns after information is placed on the LSI-1 1 bus. BRPLY 
is then applied to a sequencer which halts the 6502 and accesses the particular CSR mapped 
in the RAM. 

• Applies the BRPLY from the sequencer to the LSI-11 bus by the LSI-11 control-line inter- 
face. 



6.2.4.3 Interrupt Controller - This circuit consists of a DC003 interrupt controller chip and two 
74LS74 flip-flops. The DC003 is used in a typical manner for interrupt servicing of the LSI-1 1 bus. The 
two flip-flops hold the interrupt request (one for A and one for B) until it is serviced. When either 
request is serviced, both flip-flops are cleared by the vector signal. 
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6.2.4.4 NPR Controller - The DC010 is used in this application for doing direct memory accesses to 
the LSI-1 1 memory. Only single NPRs are allowed; HOG mode is not implemented. A description of 
the NPR operation follows. 

The microcode sets up the NPR current address and data-out registers, and then sets the A flip-flop by 
writing to the NPR register with bit 6 equal to zero. Once the NPR is initiated, the DC010 handles the 
sequence of enabling appropriate registers to transmit or receive data from the LSI-1 1 bus. This oper- 
ation is sequenced by the 5 MHz clock input to the DC010. 

When the NPR is honored, the leading edge of RPLY releases the NPR so that a second request does 
not occur. The trailing edge of RPLY sets NPR busy H to zero to indicate that the NPR transfer is 
complete. However, when doing data-out transfers, the NPR data-out register must not be updated for 
100 ns after the trailing edge of RPLY in order to comply with LSI-1 1 bus specifications. The micro- 
code can immediately service the data-in register when NPR busy H is cleared during a data-in trans- 
fer. 

The NPR abort timer is used to ensure that an NPR transfer does not take more than 16 /us. If 16 jus 
are exceeded, the transfer is aborted. The timer is set each time an NPR is initiated. 

6.2.5 Memory and Reset Control 

CSR access control allows the LSI-1 1 bus to access the CSRs. The operation is as follows. 

1. The CSR controller (Section 6.2.4.2) asserts the CSR L signal when a CSR is selected. This 
signal is used by the processor halt circuit to halt the microprocessor on the next Phase 2 
cycle if a write is not in progress. When the processor has halted, the 74LS164 shift register 
is enabled. 

2. When the first output of the shift register is true, the appropriate CSR address is selected 
and the direction of transfer is determined by the state of the WRT RAM L signal from the 
PAL. WRT RAM L sets the direction of the RAM transceivers (Section 6.2.3.2). 

3. During the next Phase 2 cycle, the CSR is either read and its contents placed onto the LSI- 
1 1 bus, or the data on the LSI-1 1 bus is written into the CSR. 

4. The next Phase 2 cycle terminates the write cycle if in the write mode, and asserts BRPLY to 
the LSI-1 1 bus. 

5. After RPLY from the DC004 drops, the microprocessor address and data bus are again con- 
trolled by the 6502. When CSR select is dropped, the microprocessor resumes operation. 

Memory and reset control also generates signals for master resetting the DM VI 1 and halting the micro- 
processor. 

6.2.6 Modem Interface 

The modem interface consists of line receivers and drivers for all modem data and control signals. The 
interface supports RS-232-C, RS-423-A, V.35, and the integral modem. Circuitry to accommodate in- 
ternal loopback for test purposes is also provided. Because the DM VI 1 supports RS-423-A for category 
1 signals (except test mode and ring), dummy generators are used for the following signals. 

• Select frequency, 

• Terminal in service, 

• New signal, 

• SRTS, 

• Remote loop, 

• Local loop, and 

• Select standby. 
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Only one interface can be enabled at a time. The modem interface select circuit enables an interface as 
selected by the interface select switch. On power-up and during any reset operation, the selected inter- 
face is disabled and loopback is selected until deselected by the microcode (Section 6.2.2.3). 

Interface to the outside world is implemented with two 40-pin Berg connectors. J2 is used for RS-232-C 
and RS-423-A with a BC55H-type cable. Jl is used for V.35 with the BC05Z cable or for the integral 
modem with the BC55F cable. 

The modem interfaces all have a null clock that is switch selectable for speeds of 56K b/s or 19.2K b/s 
and controlled by the PIA. 

6.2.7 Integral Modem 

The integral modem is used for local communications and is transformer-coupled to twinax or triax 
cables for common mode rejection and common mode voltages up to 500 V. For discussion purposes, 
the integral modem is described in two sections: receive (Figure 6-7) and transmit (Figure 6-8). 

6.2.7.1 Receive - The received data enters the modem through an isolation transformer whose output 
is directed to a differential amplifier to eliminate common mode noise. The amplifier's second stage 
uses an active Buterworth filter with an added passive filter for high and low cutoff. The filter's com- 
plimentary outputs are input to a comparator which detects zero crossover. Positive and negative transi- 
tions from the comparator clock the UP and DOWN flip-flops. All clocking is done at a clock rate 20 
times the b/s rate and the UP and DOWN flip-flops latch until cleared by the transitions (TRANS) 
flip-flop. 

When either the UP or DOWN flip-flop is set, the next clock pulse loads the transitions (TRANS) flip- 
flop which then clears the UP or DOWN flip-flop and holds it clear for one clock time. The clock input 
to the TRANS flip-flop and receive counter (REC CNTR) is 20 times the data-rate clock time. 

The REC CNTR is clocked at half clock time (or inverted 20X clock), and counts 16 clock times and 
sets the 3/4 time flip-flop. The counter is loaded if the TRANS flip-flop is set and 16 clocks have 
occurred since the last load. The counter enable is true except in an overflow condition or when oper- 
ating in half-duplex mode with the transmitter active. 

When 3/4 T is set, and the time between transitions is greater than 16 clock "times, the ID ATA flip-flop 
is clocked to one. If the transition time is less than 16 clock times when 3/4 T is set, the ID ATA flip- 
flop is clocked to a zero. The minimum time between transitions is .05 to .10 bit times as determined by 
the TRANS flip-flop clearing the UP and DOWN flip-flops. The next 3/4 T clock loads IDATA into 
the RI DATA flip-flop. The next 3/4 T clock ANDs RI DATA with IDATA, and if IDATA is zero, 
sets the I CARRIER flip-flop. IDATA is input to the receive FIFO and I CARRIER is gated with 
LINE UNIT STEP to become GRX CLK. 

The overflow flip-flop is set when no transition occurs within one and one-half bit times. Overflow then 
sets IDATA which allows the next clock pulse to clear the RI DATA and I CARRIER flip-flops until 
the next sequence of one followed by two zeros occurs. 

6.2.7.2 Transmit - The transmit circuit encodes the data into diphase space; in a square wave se- 
quence. The output is 6 V peak-to-peak into a 50 ohms load and does not exceed 15 V peak-to-peak into 
an open circuit. 

RTS allows TI CLK to set the ICS flip-flop. When the ICS flip-flop is set, the encoder flip-flop (ENC) 
is allowed to toggle with each data or TI CLK. The encoded output feeds a bipolar line driver that 
generates an ac signal with zero crossover points. The line driver output is connected to the protection 
transformer. 
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The + 5 V low circuit turns off the transistors on low logic power to keep the transmitter from gener- 
ating noise or from loading the line. During power-up, this circuit keeps the modem in the disabled state 
for several milliseconds to prevent the transmission of nonsense characters that would interfere with 
transmission in progress on a multipoint line. 

The transmitter is disabled when line units are not transferring data. The transmitter does not load the 
line when power is off. 
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CHAPTER 7 
SERVICE 



7.1 SCOPE 

This chapter provides information for servicing the DMV11. It includes the maintenance philosophy, 
troubleshooting techniques in a multipoint environment, maintenance functions, preventive mainte- 
nance, and corrective maintenance. The section on troubleshooting techniques in a multipoint environ- 
ment includes: 

• The general overall approach to multipoint troubleshooting. 

• Some common problems associated with different multipoint network configurations. 

• The use of error counters and other information for isolating problems to a specific portion of 
the physical link. 

The corrective maintenance section contains brief descriptions of the diagnostics associated with the 
DMV11. 



7.2 MAINTENANCE PHILOSOPHY 

The field replaceable unit (FRU) for the DMV11 is either a module (M8053 or M8064 micro- 
controller/line unit) or cable. Training of field service personnel is directed to functional and appli- 
cation troubleshooting, using diagnostics, for fault isolation to the FRU. Spare parts for module repair 
are not stocked in the field. Typical applications of the DMV11 do not permit lengthy troubleshooting 
sessions, and component troubleshooting/repair requires at least a 16-channel logic analyzer. 



7.3 TROUBLESHOOTING TECHNIQUES FOR MULTIPOINT 

Because of the complexity of some multipoint network configurations, there is a potential for using 
valuable time in trying to isolate a problem. For this reason, troubleshooting techniques for multipoint 
networks differ from those for point-to-point networks. 

The following sections discuss these troubleshooting techniques in terms of approach and error 
counters. 



7.3.1 Approach 

Before attempting any corrective measures, it is important to get some basic information about the 
network configuration and the nature of the problem. This information can be obtained by querying the 
user and by referring to the topology diagram for the network. The topology diagram is generated at 
installation time and is maintained by the field service representative. The flow chart (Figure 7-1) illus- 
trates a typical approach to troubleshooting from the time a service call is placed, until corrective main- 
tenance is begun. This procedure should be followed to help isolate a failing tributary before anyone is 
dispatched to a site. 
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Figure 7-1 Example of a Typical Isolation Flow Diagram (Sheet 1 of 5) 
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Figure 7-1 Example of a Typical Isolation Flow Diagram (Sheet 3 of 5) 
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Figure 7-1 Example of a Typical Isolation Flow Diagram (Sheet 4 of 5) 
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Figure 7-1 Example of a Typical Isolation Flow Diagram (Sheet 5 of 5) 
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7.3.2 Error Counters 

In multipoint networks many tributaries tie to the same transmission line. Because of this, it is more 
difficult to determine which link, if any, is causing errors. To aid in troubleshooting, the DMV11 uses 
error counters. Every DMV11 in the network (the control station and each tributary) uses error 
counters to record errors. This allows user programs at any DM VI 1 in the network to determine overall 
error rates and to detect a malfunctioning link. 

The main way in which errors are indicated to the DMV11 is by DDCMP negative acknowledge mes- 
sages (NAKs). Each NAK contains an address field and a reason code that identifies the source and 
reason for the NAK. In general, when an error is detected in an incoming message, the station that 
receives the message sends a NAK to the station that sent the message. By recording NAKs sent and 
NAKs received, each point or tributary in the network is able to compile statistics on the condition of 
the link established between the two stations. DDCMP has been designed so that even if one of the 
stations on the link cannot record errors, the other station may be used to record errors for all commu- 
nications in both directions on the link. 

There are three main categories of error counters used by the DMV11; data link counters, station 
counters, and threshold counters. Data link counters and threshold counters are maintained for each 
tributary /control station pair on a physical link. These counters are located in the tributary status slots 
(TSS) of the data memory (Figure 7-2). Station counters are maintained for the physical link as a 
whole, and are located in the global status slots (GSS) of the data memory (Figure 7-3). The informa- 
tion gained by checking error counters may be helpful in pinpointing a problem area. 

7.3.2.1 Data Link Error Counters - Data link counters are of two types; cumulative and background. 
The cumulative counters are 8-bit counters which latch at 255. The background counters are 16-bit 
counters which latch at 65535. The cumulative data link counters record and total all occurrences of an 
error and group them into the following categories. 

• Data errors outbound, 

• Data errors inbound, 

• Local reply timeouts, 

• Remote reply timeouts, 

• Local buffer errors, 

• Remote buffer errors, 

• Selection timeouts. 

Background data link counters are used to provide a statistical base for the cumulative error counters 
and therefore record: 

• The number of data messages transmitted, 

• The number of data messages received, and 

• The number of selection intervals. 

A point-to-point station maintains a single set of data link counters. Multipoint stations (control and 
tributary) maintain a separate set of data link counters for each established tributary. Data link 
counters are cleared by: 

• A master clear of the DM VI 1, 

• A control command to establish the tributary, or 

• A user-issued control command to read and clear the TSS error counters. 

Data Errors Outbound - This 8-bit group counter records NAKs received for data errors occurring on 
the communications channel outbound from this station. There are three types of outbound errors for 
which this counter records NAKs received; header blockcheck (OHBCC), data field blockcheck 
(ODBCC), and reply response (OREP). Three separate flag bits indicate which type of outbound error 
is being counted. 
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OHBCC (outbound header blockcheck) is set when a NAK with a reason code of one is re- 
ceived for a header block-check error for either data or control messages. 

ODBCC (outbound data field blockcheck) is set when a NAK with a reason code of two is 
received for a data field block-check error. 

OREP (outbound reply response) is set when a NAK with a reason code of three is received 
for a reply message response. 
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Figure 7-3 Station Error Counters 



Data Errors Inbound - This 8-bit group counter records occurrences which normally result from data 
errors on the communications channel inbound to this station. Three separate bits indicate specific error 
types associated with this counter. 

• IHBCC (inbound header blockcheck) is set when messages having header block-check errors 
are received. When this error occurs, point-to-point stations and multipoint control stations 

• send a NAK with a reason code of one. A multipoint control station records this error for the 
selected tributary regardless of the address field in the received message. A multipoint tri- 
butary records this error only if the address field matches its station address. 

• IDBCC (inbound data field blockcheck) is set when NAKs with a reason code of two are to 
be sent for data field block-check errors. 

• I REP (inbound reply response) is set when NAKs with a reason code of three are to be sent 
for a reply response. 

Local Reply Timeouts - This 8-bit counter records occurrences which result from: 

• The loss of communications between two stations while the one recording this error has data 
to transmit, or 

• The choice of an inappropriate value for the reply timer. 
Specifically, this error counter records the sending of a REP message. 

Remote Reply Timeouts - This 8-bit counter records occurrences which result from: 

• The loss of communications between two stations while the remote station has data to trans- 
mit, or 

• The choice of an inappropriate value for the remote station reply timer. 

Specifically, this counter records ACKs sent in response to a REP. The remote station sent a REP 
because it received no acknowledgement for messages it previously sent. The local station received 
those messages, but the remote station never received the acknowledgement. 
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Local Buffer Errors - This 8-bit counter records the fact that the user program at the station recording 
the error failed to properly allocate receive buffers to data messages from the remote station. Two sepa- 
rate bits indicate the specific errors associated with this counter. 

• LBTU (local buffer temporarily unavailable) is set when a buffer is temporarily unavailable. 
This condition indicates that a NAK with a reason code of eight is to be sent. 

• LBTS (local buffer too small) is set when a local buffer is too small for the incoming mes- 
sage. This condition indicates that a NAK with a reason code of 16 is to be sent. 

Remote Buffer Errors - This 8-bit counter records the fact that the user program at the remote station 
failed to properly allocate receive buffers to data messages from the station recording the error. Two 
separate bits indicate the specific errors associated with this counter. 

• RBTU (remote receive buffer temporarily unavailable) is set when a NAK with a reason 
code of eight is received. 

• RBTS (remote receive buffer too small) is set when a NAK with a reason code of 16 is re- 
ceived. 

Selection Timeouts - This 8-bit counter records the occurrences which result from: 

• Loss of communications with a remote station, 

• Data errors on the communications channel to or from the remote station, and 

• The choice of an inappropriate value for this station's select timer. 

This counter is used only by half-duplex point-to-point or multipoint control stations. Two separate bits 
indicate the specific errors associated with this counter. 

• NRTS (no reply to select) is used to record selection intervals in which no transmission is 
received from the tributary, and no attempt to transmit is detected. Specifically, it records 
the expiration of the select timer without the receipt of a valid control message or header, or 
the detection of an attempted transmission. 

• IRTS (incomplete reply to select) is used to record selection intervals which were not proper- 
ly terminated. Specifically, it records the expiration of the select timer preceded by receipt 
of a valid control message, receipt of a valid header, or detection of an attempted transmis- 
sion. An attempted transmission is indicated by: 

- The presence of a carrier signal, 

- The receipt of a DDCMP synchronization sequence, and 

- The receipt of an SOH, ENQ, or DLE. 

Data Messages Transmitted - This 16-bit counter records messages transmitted by this station, and 
latches at a count of 65535. It can be used as a statistical base when evaluating data errors outbound, 
local reply timeouts, and remote buffer errors. Messages sent as a result of retransmission are not in- 
cluded in this count. 

Data Messages Received - This 16-bit counter records messages received by this station, and latches at 
a count of 65535. It can be used as a statistical base when evaluating data errors inbound, remote reply 
timeouts, and local buffer errors. Messages received out of sequence or in error are not included in this 
count. 
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Selection Intervals - This 16-bit counter records the number of times this station selects the other sta- 
tion. It also latches at a count of 65535. Specifically, it records the number of messages transmitted 
with the select flag on. It is only used by half-duplex point-to-point and multipoint control stations. It 
can be used as a statistical base when evaluating the number of selection timeouts. 

7.3.2.2 Station Error Counters - Station counters are 8-bit counters which latch at 255 and record 
unusual occurrences. These occurrences may be the result of: N 

• A hardware or software fault at this station, 

• A hardware or software fault at a remote station, or 

• A data error on the communications channel undetected by the header block-check field. 
A single set of these counters is used for all tributaries on a multipoint link. 

There are four types of station counters: 

1. Remote station errors, 

2. Local station errors, 

3. Global header block-check errors, and 

4. Maintenance data field block-check errors. 

Station counters are cleared by: 

• A master clear of the DM VI 1, or 

• A user-issued control command to read and clear the GSS error counters. 

Remote Station Errors - This 8-bit counter records occurrences caused by a fault in a remote station or 
by an undetected data error on the channel inbound to this station. Four separate bits indicate the spe- 
cific errors associated with this error counter. 

• ROVRN (remote receive overrun) is set when a NAK with a reason code of nine is received 
for a receive overrun. 

• RMHFE (remote message header format errors) is set when a message is received which has 
a header format error. This condition indicates that a NAK with a reason code of 17 is to be 
sent. 

• RSEL (remote selection address error) is set when a multipoint control station receives a 
message containing an address field which does not match the address of the currently se- 
lected tributary. This error is recorded only by multipoint control stations. 

• RSTR (remote streaming tributary) is set by either one of two events: 1) an implementation- 
dependent maximum transmission interval is exceeded without releasing the channel (babbl- 
ing tributary), or 2) the channel is not released following the end of a selection interval 
(streaming tributary). 

Local Station Errors - This 8-bit counter records occurrences caused by a fault in a local station or by 
an undetected data error on the channel outbound from this station. Four separate bits indicate the 
specific errors associated with this error counter. 

• LOVRN (local receive overrun, NAK sent) is set for local station receive overruns. This con- 
dition indicates a NAK with a reason code of nine is to be sent. 
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• LOVR (local receive overrun, NAK not sent) is set by a receive overrun when a NAK is not 
sent. For a multipoint tributary, this happens if an overrun occurs while receiving a header. 
For other stations, this occurs when the station is not in the DDCMP run state. 

•• LUNDR (local transmit underruns) is set when a transmit underrun occurs. 

• LMHFE (local message header format error) is set when a NAK with a reason code of 17 is 
received to indicate a message with a header format error was sent by this station. 

Global Header Block-Check Errors - This 8-bit counter records the occurrence of header block-check 
errors that are not recorded on a per tributary basis. Specifically, it counts header block-check errors 
for maintenance messages and for messages to tributaries where the address field does not match the 
station address. 

Maintenance Data Field Block-Check Errors - This 8-bit counter records the occurrence of data field 
block-check errors for maintenance messages. 

7.3.2.3 Threshold Error Counters - Threshold error counters are used to determine if a persistent fault 
exists. A persistent fault is one which occurs seven consecutive times. Whenever a threshold counter 
reaches its maximum value (7), the user program is notified by a control response. 

In the DDCMP run state, threshold counters are cleared when the user is notified. In this way the user 
is continually informed of a persistent fault. In the DDCMP ISTRT and ASTRT states, threshold 
counters are not cleared when the user is notified. In this way the user is not continually informed of an 
inoperative remote station. 

A point-to-point station maintains a single set of threshold counters. A multipoint control station main- 
tains a separate set for each tributary. A multipoint tributary maintains a single set unless it supports 
multiple tributary addresses in which case it maintains a single set for each established tributary ad- 
dress. 

There are three types of threshold error counters: transmit, receive, and selection. 

Transmit Threshold Errors - This 3-bit counter is incremented (if less than 7) in the following instances. 

1. The DMV11 is in the ISTRT state when a STRT message is sent, 

2. The DM VI 1 is in the ASTRT state when a STACK message is sent, or 

3. The DMV11 is in the run state and a NAK with a reason code other than three (REP re- 
sponse) is received, or when this station sends a REP message. 

The transmit threshold error counter is cleared: 

• Upon entering the ISTRT, ASTRT, or run states. 

• While in the run state one of the following occurs. 

- A transmit threshold error is reported, 

- A NAK, ACK, or data message is received acknowledging a new message, or 

- A NAK, ACK, or data message is received when no messages are outstanding. 
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Receive Threshold Errors - This 3-bit counter is incremented (if less than seven) when a NAK with one 
of the following reason codes is sent. 



Reason Code Description 

1 Header block-check error. 

2 Data field block-check error. 

3 REP response. 

8 Buffer temporarily unavailable. 

9 Receive overrun. 

16 Message header format error. 



This counter is cleared when: 

• Entering the' ISTRT, ASTRT, or run states, 

• A control message with a correct header blockcheck is received without a header format er- 
ror, 

• A data message with correct header and data field blockchecks is received without a header 
format error, or 

• In the run state, a receive threshold error is reported. 

Selection Threshold Errors - This 3-bit counter is only used by multipoint control stations and half- 
duplex point-to-point stations. It is incremented (if less than seven) when a selection timeout occurs. 

It is cleared upon receipt of a message with the select bit set, or while in the run state and a selection 
threshold error is reported. 

7.3.3 Error Counter Analysis 

In most applications the software operating system records all the error counters, but does not attempt 
to analyze or take any particular action of its own as a result of any specific errors. 

The system manager or another operator instructs the software to retrieve the counters. The counters 
are analyzed by the operator or system manager and then the software is instructed to perform a specif- 
ic function relative to the counter indications. 

For information on retrieving the counters, refer to the system-specific DECnet System Manager's 
Guide or consult the network manager. 

The following example serves to illustrate how the counters can be used in diagnosing a system failure 
(refer to Figure 7-4). A user should keep in mind that DCLT also allows access to error counters. See 
Section 7.6.5. 

Assume that a full-duplex multipoint network is made up of seven tributaries and a control station as 
shown in Figure 7-4. The type of electrical interface (EIA RS-232/RS-449, V.35, integral modem) is 
not important in this example. The system manager at the control station notices that data transfers 
over the network appear to be "sluggish." Some standard file transfers are taking a longer time than 
usual to complete. (Note that in some cases this could be caused by a sudden increase in traffic on the 
network.) The problem appears to be intermittent in nature since no threshold errors have occurred and 
data is still being transferred between all tributaries. The system manager examines the error counters 
at the control station for tributary seven. They are as follows. 
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Figure 7-4 Full-Duplex Seven Tributary Multipoint Network 



ERROR COUNTERS FOR TRIBUTARY SEVEN (AT THE CONTROL STATION) 
DATA ERRORS OUTBOUND = 

DATA ERRORS INBOUND = 255 (IREP, IDBCC, IHBCC) 

LOCAL REPLY TIMEOUTS = 40 

REMOTE REPLY TIMEOUTS = 

LOCAL BUFFER ERRORS = 

REMOTE BUFFER ERRORS = 

SELECTION TIMEOUTS = 50 (IRTS) 

DATA MESSAGES TRANSMITTED = 420 

DATA MESSAGES RECEIVED = 310 

SELECTION INTERVALS = 212 

The data errors inbound counter (which is latched) indicates that NAKS have been sent: 

• For header BCC errors (IHBCC), 

• For data BCC errors (IDBCC), and 

• In response to receiving a REP (IREP). 

Local reply timeouts show that REP messages have been sent to the tributary because acknowledg- 
ements for outstanding messages have not been received. Selection timeouts have also occurred where 
the tributary received a poll and transmitted (raised carrier) but did not deselect itself (incomplete re- 
ply to select - IRTS). From the information gathered so far, there appears to be a problem on the link 
between the tributary's transmitter and the control station's receiver. This is reenforced by the fact that 
there are no data errors outbound indicating that NAKS have not been received from the tributary. The 
problem could be in the control station's receiver hardware (DMV11, modem, and so forth), the cable 
to the tributary, or the tributary's transmitter hardware (DMV1 1, modem, and so forth). The next log- 
ical step is to examine the error counters at the control station for the other tributaries. Upon doing this 
the system manager notices that tributary six has the same type and relative number of errors as tri- 
butary seven. This indicates that the problem is in the control station's receiver or the cable from tribu- 
taries six and seven. (It could be that both tributaries six and seven have transmitter problems, but this 
is unlikely.) Examination of the error counters for the remaining tributaries reveals very few errors. 
This rules out the control station hardware. 

NOTE 

If failures occur at the control station, they are in- 
dicated by the fact that in most cases all stations are 
affected. 

The problem appears to be an intermittent cable fault on the control station's receive line (tributaries 
transmit line) between tributaries five and six. (Note that this could also be a modem-related problem if 
tributaries six and seven share the same modem by using a modem splitter.) More information about 
the problem can be gained by examining the error counters at the tributary end of the link. 

ERROR COUNTERS FOR TRIBUTARY SEVEN (AT THE TRIBUTARY STATION) 

DATA ERRORS OUTBOUND = 255 (IREP, IDBCC, IHBCC) 

DATA ERRORS INBOUND = 

LOCAL REPLY TIMEOUTS = 23 

REMOTE REPLY TIMEOUTS = 40 

LOCAL BUFFER ERRORS = 

REMOTE BUFFER ERRORS = 

SELECTION TIMEOUTS = N/A 

DATA MESSAGES TRANSMITTED = 310 

DATA MESSAGES RECEIVED = 420 

SELECTION TIMEOUTS = N/A 
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Notice that these error counters provide the same type of information as the control station error 
counters. The errors all seem to be in one direction, namely outbound. Notice also that the number of 
data messages transmitted and received match those at the control station. Since data transfer is occur- 
ring, the likelihood of a hard error in the hardware is low. 

NOTE 

Hard errors at the control or tributary stations gen- 
erally are revealed during the start-up sequence. 

Examination of the remainder of the tributary's error counters reveals that tributary six has errors sim- 
ilar to tributary seven, and the other tributaries have very few errors. The "sluggishness" of the network 
is due to the: 

• Timeouts that intermittently occur when polling tributaries six and seven, and 

• Numerous retransmissions that occur in order to get the data transferred. 

These timeouts and retransmissions of data are the result of a cable fault between tributary five and six 
as indicated in Figure 7-4. 

7.4 MAINTENANCE 

For maintenance purposes the DMV11 may be operated in two basic modes: 

1 . Maintenance mode, or 

2. Standard operating mode. 

7.4.1 Maintenance Mode 

Maintenance mode is used to test the DM VI 1 by causing the microcode to respond to certain command 
functions issued by a diagnostic program. Section 4.8 discusses the maintenance mode in detail. 

7.4.2 Standard Operating Mode 

The DMV1 1 is tested in the standard operating mode by terminating the cable at the BC55F or BC55H 
panel or at the modem end of the external cable, and running diagnostics. 

The DMV11 options are configured as follows: 

1. DMV1 1-AA (for RS-232-C; RS-423-A) 

• The modem must be disconnected and the test connector must be attached to the cable. 
This may be done at the BC55H panel or at the modem end of the external cable. 

EIA Test Connector Interface Cable Modem Cable 

RS-232-C H325 BC55H BC05D-25 

RS-423-A H3251 BC55H BC55D-33 

• The clock signal is looped back in the test connector to simulate modem transmit and 
receive clocks. The data rate for this application must not exceed 19.2K b/s. 

• Modem control signals are tested for proper level conversion and cable paths. These 
signals are looped back in the test connector as shown in the signal flow of Figure 2-8 
View E. 
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2. 



DMV11-AB (CCITT V.35/DDS) 



• The modem must be disconnected and the H3250 test connector must be attached to 
the BC05Z-25 cable. 

• The clock signal is looped back in H3250 to simulate modem transmit and receive 
clocks. 

• Modem control signals are tested for proper level conversion and cable paths. These 
signals are looped in the H3250 as shown in the signal flow of Figure 2-8 View B. 



3. DMV11-AC (for integral modem local use) 

• The local link connections of the BC55F connector panel are disconnected at the local 
panel, and the FDX switch on the BC55F connector panel is switched to half-duplex to 
accomplish the external loopback. 

CAUTION 

If DMV11 is connected to another running DMV11, 
disconnect the cable at the BC55F Connector panel 
during diagnostic execution. 

• The data is looped back through the BC55F connector panel to test, transmit, and re- 
ceive data. The data rate for this application must be 56K b/s. 



7.5 PREVENTIVE MAINTENANCE (PM) 

There is no specific DM VI 1 PM schedule. A general check of voltages and connections should be done 
when system PM is performed. After handling DM VI 1 modules or cables, a complete checkout of the 
device, by running all diagnostics and, if possible, the interprocessor test, is required. 



7.6 CORRECTIVE MAINTENANCE 

Since the FRU is either a module or cable, all corrective diagnosis should be directed towards isolating 
the failing FRU. DMV11 diagnostics are designed to aid in the isolation process and should be run 
starting with the DMV11 static logic test and continuing to the DEC/XII program. The proper se- 
quence of diagnostics is shown in Table 7-1. 



7.6.1 DMV11 Static Logic Tests Parts 1 and 2 

These diagnostics test the DMV1 1 microcontroller circuits except for the USYRT. Through dialogue 
with the operator and by using the diagnostic supervisor (DS), the program allows modification of de- 
vice parameters, such as the LSI- 11 bus address, vector address, and processor type. 

These programs are compatible with the stand-alone diagnostic supervisor and do not exceed 16K of 
memory. The total time required to run DMV11 static tests is approximately from 30 seconds to 2 
minutes per pass, depending on the CPU type. 

DMV11 static logic tests part 1 and part 2 are compatible with XXDP+, ACT/SLIDE, and APT. 
XXDP+ and ACT/SLIDE may be run in dump or chain modes. APT can be run in program or script 
modes. A summary of the tests performed are listed in Tables 7-2 and 7-3. 



7-17 



Table 7-1 DMV11 Diagnostics 



Diagnostic 


Description 


(C)VDMA** 


DM VI 1 static logic test part 1 


(C)VDMB** 


DM VI 1 static logic test part 2 


(C)VDMC** 


DM VI 1 static logic test part 3 


(C)VDMD** 


DM VI 1 static logic test part 4 


(C)VDME** 


DM VI 1 static logic test part 5 


(C)ZDMT** 


DM VI 1 functional diagnostic 


(C)ZCLM** 


DMV11 DCLT program 


(C)XDMD** 


DM VI 1 DEC/XII master module 


(C)XDME** 


DMV1 1 DEC/XII slave module 



Indicates the revision level 



Table 7-2 DMV11 Static Logic Test Part 1 Diagnostic Summary 



Test Number 


Description 


1 


DMV11 availability 


2 


Master clear, run microdiagnostics 


3 


CSR addressing 


4 


CSR registers data read/write 


5 


Basic master clear 


6 


Bus reset 


7 


CSR, maintenance microcode interaction 


8 


Run flip-flop 


9 


Low RAM (00-0F) scratchpad 


10 


Data RAM moving inversions (LOC's 00 1 8-0 1 FF hex) 


11 


VIA register addressing 


12 


VIA's DDRB data read/write 


13 


VIA's DDRA data read/write 


14 


VIA's ORB data read/write 


15 


VIA's timer #1 data read/write 


16 


VIA's shift register data read/write 


17 


VIA's ACR data read/write 


18 


VIA's PCR data read/write 


19 


VIA's IER data read/write 


20 


VIA's ORB/DDRB master clear test 


21 


VIA's DDRB master clear test 


22 


VIA's DDRA master clear test 


23 


VIA's shift register master clear test 


24 


VIA's ACR master clear test 


25 


VIA's PCR master clear test 


26 


VIA's IER master clear test 
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Table 7-3 DMV11 Static Logic Test Part 2 Diagnostic Summary 



lest Number 


Description 


1 


VIA timer 2 one shot mode 


2 


VIA s SR input (MODE 2) - system clock mode 


3 


NPR control register - master clear 


4 


NPR data-out 


5 


NPR data-in 


6 


NPR XFFR abort 


7 


NPR extended address bit test 


8 


Special MFG extended bit test 


9 


Q-Bus interrupt "A" & "B" selection 


10 


Bus reset with disable init set 


11 


Master clear with disable init spt 


12 


DCOK H LO bit 


13 


Halt mode verification 



7.6.2 DMV11 Static Logic Tests Parts 3, 4, and 5 

These diagnostics perform static tests of USYRT read/write logic; basic transmitter functions; receiver 
sequencing and data buffering; and static operations in character and bit-stuffing modes. In addition, 
data messages are sent at TTL level or through an external test connector with a specific modem inter- 
face selected. 

Static logic tests provide troubleshooting capabilities such as tight-scope loops, switch options, and the 
ability to lock on intermittent errors. Additional tests provide fault isolation to facilitate replacement of 
the smallest field replaceable unit. 

These programs conform to the stand-alone version of the diagnostic supervisor and are compatible with 
ACT, APT, XXDP-f , and SLIDE. Through dialogue with the operator, the programs permit modifica- 
tions of device parameters such as the LSI-1 1 bus address, vector addresses, and device priority. The 
operator can specify particular tests to be run and a variety of looping, running, and reporting modes. 

Device errors are reported as they occur. The report includes the test number and error description, 
good and bad test data, and applicable device register contents. 

A summary of the tests performed are listed in Tables 7-4, 7-5, and 7-6. For greater detail, refer to the 
diagnostics listings. 



Table 7-4 DMV11 Static Logic Test Part 3 Diagnostic Summary 



Test Number 


Description 


1 


TBMT microcode interrupt test 


2 


Switch setting test 


3 


USYRT master clear test 


4 


USYRT program reset test 


5 


USYRT register addressing test 


6 


R/W bit test of PCSAR high point 
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Table 7-4 DMV11 Static Logic Test Part 3 Diagnostic Summary (Cont) 



Test Number 


Description 


7 


R/W bit test or S/AR register 


8 


R/W bit test of PCR register 


9 


R/W bit test of TDSR register s nigh byte 


10 


R/W bit test of TXDB register 


11 


Pseudo R/W bit test or RXDB 


12 


Pseudo R/W bit test of RDSR s high byte 


13 


Null clock test 


14 


BCP TX reset w/lDLE = 


15 


T"»y"^T> a ... /TTVT "C 1 

BCP TX reset w/lDLE = 1 


16 


BCP TX underrun w/TSOM termination 


17 


BCP TX underrun w/Rb!Sbl termination 


1 o 


BCP 1 A disable test 


19 


FIFO stacking characters test 


20 


BCP character length test 


21 


BOP TX TABORT/(lDLb = 0) test 


22 


T>/~\T> TV T A D f^VT") T // T FA I TJ 1 \ + + 

BOP IX 1 ABOKl/(lL)Lb = l)test 


23 


BOP TX TXGA (transmit go-ahead) test 


24 


BOP TX message without CRC 


25 


BOP RX character length test 


26 


TX "spacing sequence" 


27 


FIFO overrun integrity test 


28 


BCP PX overrun set and clear test 


29 


BCP RX sync-character recognition 


30 


BCP RX strip-sync test 


31 


BCP RX lost RXE test 



Table 7-5 DMV11 Static Logic Test Part 4 Diagnostic Summary 



Test Number 


Description 


1 


VRC parity generation test 


2 


VRC error detection test 


3 


BCP CRC generation/detection test 


4 


BOP RX basic receive/flag recognition test 


5 


BOP RX secondary station addressing 


6 


BOP RX all parties address test 


7 


BOP RX bit stuffing test 


8 


BOP RX underrun idle aborts/flags 


9 


BOP RX lost RXE test 


10 


BOP RX GA (go-ahead) recognition 


11 


BOP RX "ABC" test 
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Table 7-6 DMV11 Static Logic Test Part 5 Diagnostic Summary 



Test Number 


Description 


1 


RX data flushing test 


2 


Integral modem interface test 


3 


Data test - BCP external loopback (XLB) CRC-16 


4 


Data test - BCP XLB odd VRC 


5 


Data test - BCP XLB even VRC 


6 


Data test - BOP XLB CRC-CCITT-1 


7 


Data test - BOP XLB CRC-CCITT-0 


8 


Modem control signal loopback test 


9 


DDCMP message test 



7.6.3 DMV11 Functional Diagnostic 

This diagnostic performs testing on the DMV1 1 option in a functional manner to verify its proper oper- 
ation under microcode controlled use of the DDCMP. This includes a ROM CRC/CCITT check, mi- 
crodiagnostic, command utilization, and error generation. 

This functional test provides troubleshooting capabilities such as tight-scope loops, switch options, and 
the ability to lock on intermittent errors. Additionally, this program conforms to the stand-alone version 
of the diagnostic supervisor and is compatible with APT, ACT, XXDP+, and SLIDE. 

Through dialogue with the operator, the program permits modification of device parameters such as the 
LSI- 11 bus address, vector addresses, and device priority. The operator can specify particular tests to 
be run and a variety of looping, running, and reporting modes. 

A summary of the tests performed are listed in Table 7-7. For greater detail, refer to the diagnostics 
listings. 



7.6.4 DMV11 Microdiagnostic Error Reporting 

Internal diagnostics test registers and data paths that are internal to the microprocessor. These diagnos- 
tic routines run automatically on a master clear and must complete successfully before normal inter- 
action with the CPU can take place. 

The user program is notified of the results by way of the CSRs. Table 7-8 is a summary of the possible 
results. 



7.6.5 Data Communications Link Test Program (DCLT) 

DCLT is a communications equipment maintenance tool designed to verify DMV11 to DMV11 com- 
munication links. The DCLT program provides the coverage necessary to isolate the following faults: 

• Communications interface program functionality, 

• Communication modem, 

• Communication cabling and installation, and 

• Physical link/network. 
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DCLT programs allow testing between modes with different hardware interfaces implementing the 
same or compatible protocol. The DCLT program can be exercised under normal maintenance loop- 
back tests: 

• Internal TTL loopback, 

• Hardware loopbacks: 

- Module test connectors, or 
Cable test connectors, 

• Manual-controlled local modem analog and digital loopback functions (full-duplex mode), 

• Programmable-controlled local modem analog loopback (full-duplex mode), 

• Programmable-controlled remote modem digital loopback (full-duplex mode). 

DCLT's main goal is to test the communications link. DCLT assumes that the CPUs and DMVlls at 
each end of the link have previously been tested and found to be in proper working order. 

Prior to analyzing any data, the user must have a thorough understanding of the protocol formats appli- 
cable to the system under test. 

DCLT may be used to access DMV1 1 error counters or other information by using the print command. 
The print command invokes a DCLT level called REPORT within which the following commands are 
available. 



Command 

HELP OR? 
TSS NNN/SW 

ERROR 
FULL 
OFFSET = 
GSS/SW 

LOG 
EXIT 



NN 



Description 

Prints help information for RPT. 

Shows tributary status slot information where NNN is the decimal tributa- 
ry address and SW is one of the following switches. 

Indicates that only error slots are to be printed. 

Indicates that all tributary status slots are to be printed. 

Indicates that the tributary status slot whose offset is NN is to be printed. 

Print the global status information. 
Switches are the same as for TSS. 

Dumps the event log. 

Exits back to the command level that the user entered from. [DCLT> or 
DP>]. 



DCLT is XXDP+ or APT compatible and runs under control of the diagnostic supervisor (DS). It 
requires 24K of memory. For more information on DCLT refer to the (C)ZCLM** document. 
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Table 7-7 DMV11 Functional Diagnostic Summary 



Test Number 


Description 


1 


Address test 


2-7 


DMP ROM verification tests 


8-9 


DMV ROM verification tests 


10 


Initialization test 


11 


DMP interface diagnostics 


12 


RDI remains set test 


13 


Test for RDO setting 


14 


Check for procedure error 100 


15 


Check for procedure error 104 


16 


Test mode change of duplex portion of mode 


17 


Test for max tribs to be established 


18 


Read/write tributary status slots test 


19-20 


Tests for procedure error 132 


21 


Test for read/clear command 


22 


Tests for global status slots 


23 


Halt trib command tests 


24 


Kill trib command tests 


25 


Check for procedure error of 102 


26 


Check for procedure error of 1 10 


27 


Check for procedure error of 120 


28 


Check for procedure error of 134 


29 


Latch/unlatch poll check 


30 


Short message sending test 


31 


Check for procedure error 1 22 


32 


Check for procedure error 1 24 


33 


Check for procedure error 126 


34 


Check for procedure error 130 


35 


Transmit/receive 256 bytes, MTP, DDCMP 


36 


DMV Q22 mode TX/RX 256 bytes, MTP, DDCMP 


37 


Transmit/receive 255 bytes, MTP, DDCMP 


38 


DMP read/write modem register tests 


39-41 


Test of mem extension bits 


42 


Test for TX/RX 257 byte 


43 


Test for TX/RX l byte 


44 


Polling state tests 
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Table 7-8 Microdiagnostic Error Codes 



BSEL6 


BSEL4 


Description 


101 


N/A 


Branch test has failed and the microcode is spinning in a loop. 


102 


N/A 


6502 internal register test has failed and the microcode is spinning in a loop. 


103 


N/A 


Load and store instructions test has failed and the microcode is spinning in a 
loop. 


104 


N/A 


Compare instructions test has failed and the microcode is spinning in a loop. 


105 


N/A 


Increment and decrement instructions test has failed and the microcode is spin- 
ning in a loop. 


106 


N/A 


Shift and rotate instructions test has failed and the microcode is spinning in a 
loop. 


107 


N/A 


Logic instructions test has failed and the microcode is spinning in a loop. 


110 


N/A 


Add with carry, subtract with carry, set and clear decimal mode instructions 
test has failed and the microcode is spinning in a loop. 


111 


N/A 


Stack push and pull instructions test has failed and the microcode is spinning in 
a loop. 


112 


N/A 


Subroutine instructions test has failed and the microcode is spinning in a loop. 


113 


N/A 


Ram scratchpad, CSR, and NPR address resisters addressing test has failed 
and the microcode is spinning in a loop. 


114 


N/A 


Ram scratchpad, CSR, and NPR address resisters data test has failed and the 
microcode is spinning in a loop. 


115 


N/A 


True interrupt test has failed and the microcode is spinning in a loop. 


116 


N/A 


Ram data and addressing test has failed and the microcode is spinning in a loop. 


117 


N/A 


Ram alternating data test has failed and the microcode is spinning in a loop. 


120 


N/A 


Indexed indirect addressing mode instruction test has failed and the microcode 
is spinning in a loop. 


121 


N/A 


Line unit message test has failed and the microcode is spinning in a loop. 


305 


33 


The microdiagnostics have completed without errors. 
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7.6.6 DEC/X11 DMV11 Modules 

There are two DEC/X11 modules for the DMV11; DMD* and DME*. Together these two modules 
can operate: 

• Up to 16 DMV11 devices in point-to-point links. 

• A single DMV11 configured as a multipoint control station communicating with up to 12 
tributaries. 

• Up to 16 devices configured as multipoint tributaries on the same LSI- 11 bus. 

These modules transmit, receive, and check 32 data messages of 1024 bytes each on a given physical 
link. By default, this involves a single LSI-1 1 system with one or more devices operating in internal or 
external loopback mode. However, by operator selection of nondefault modes, actual point-to-point or 
multipoint operation is possible. 

7.6.6.1 DMD* - DMD* is the master module. It can operate up to 16 DMV1 1 devices in looped-back 
and point-to-point modes, or a single device in multipoint control mode. DMD* can be self-sufficient or 
it can communicate with slave modules on the same or another processor. 

A separate DMD* module is required for each group of looped-back DMV11 devices, each control 
station, or each group of point-to-point devices. 

The actual operating mode for each DMD* module is selected by software switch registers for that 
module. The DMD* module uses switch registers SR1-SR4 as follows: 

SR4 has three allowable values: 0, 1, or 2. 

SR4 = :IF TESTING DMP1 1 
SR4= 1 :IF TESTING DMV1 1 

SR4 = 2 :IF TESTING DMV1 1 (AND Q22 SOFTWARE MODE IS DESIRED). 
SRI has three allowable values; 0, 1, or 2. 

When SR1=0: 

• All selected DMVlls run in point-to-point full-duplex mode with internal or external loop- 
back on all devices. 

• SR2 has the following meaning: 

If SR2 = 0, internal loopback is provided by the program. This is accomplished using TTL- 
level loopback on the line unit. SR2=0 is the default mode of operation. 

If SR2=1, external loopback is provided by H3254 or H3255 test connnectors on each de- 
vice. 

If SR2 = 2, cable loopback is provided by H3250 or H3251 test connectors. 
When SR1 = 1: 

• All selected DMVlls run in point-to-point full- or half-duplex mode without loopback. 

• The DMD* module communicates with DME* (slave) modules on the same or other LSI-1 1 
systems. 
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• SR2 and SR3 software switch registers are not used. 
When SRI =2: 

• Only one DMV11 is selected. 

• The selected DM VI 1 runs in multipoint control full- or half-duplex mode without loopback. 

• The DMD* module communicates with DME* (slave) modules on the same or other LSI-1 1 
systems. 

• SR2 = The total number of tributaries on this multipoint link. The allowable range is from 1 
to 14 8 . 

• SR3 = The starting tributary address. The program uses this starting address to compute the 
other addresses. The allowable address range is from 1 to 377s and they may wraparound 
(377 to 1) if necessary. 



7.6.6.2 DME* - DME* is the slave module. It can operate up to 16 DMV1 1 devices in point-to-point 
slave or multipoint tributary modes. 

A separate DME* module is required for each group of point-to-point slaves or multipoint tributaries 
on a system. 

As with the DMD* module, the actual operating mode for each DME* module is selected by software 
switch registers for that module. The DME* module uses software switch registers SR1-SR4 as follows: 

SR4 has three allowable values: 0, 1, or 2. 

SR4=0 :IF TESTING DMP1 1 
SR4= 1 :IF TESTING DMV1 1 

SR4 = 2 :IF TESTING DMV1 1 (AND Q22 SOFTWARE MODE IS DESIRED). 
SRI has two allowable values; and 1. 
When SRI =0: 

• All selected DMV11 devices run in point-to-point slave, full- or half-duplex mode without 
loopback. 

• The DME* module communicates with the DMD* (master) modules on the same or other 
LSI-1 1 systems. 

• SR2 and SR3 are unused. 
When SRI = 1: 

• All selected DMV11 devices run in multipoint tributary full- or half-duplex mode without 
loopback. 

• The DME* module communicates with a DMD* (master) module on the same or other LSI- 
11 systems. 
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• SR2 = The total number of tributaries on the multipoint link on this CPU. The allowable 
range is from 1 to 14s- 

• SR3 = The starting tributary address. The program uses this starting address to compute the 
other addresses. The allowable address range is from 1 to 377s and they may wraparound 
(377 to 1) if necessary. 

NOTE 

If the DMV11 DEC/X11 modules are configured to 
run in linkmode, it is recommended that the exercis- 
er be started in run lock mode. If this is not done, the 
exerciser may hang. 

7.6.7 Soft Error Reports Under DEC/X11 

Soft errors indicate errors which occurred causing a message retransmission. The DMD* module 
requests data errors inbound and outbound for each pass. If any errors are present, they are reported as 
soft errors. The soft error report may be used in the isolation of certain DMV1 1 failures from UNIBUS 
loading or data late problems. 

The DM VI 1 has no data late bit or capabilities for detecting the fact that it did not obtain bus master- 
ship in time to service the synchronous line. The DM VI 1 interprets such a condition as an error in the 
synchronous data stream (a BCC error, transmitter underrun, or receiver overrun) and DDCMP causes 
the message to be retransmitted. This occurrence causes incrementation of the cumulative error 
counters in DMV11 RAM memory. 

A process of elimination must be used to determine whether soft errors (BCC) are caused by bus la-, 
tency or failing DMV11 hardware. 

Typically, the DM VI 1 should show no errors when running in a local loopback mode. This is normally a 
noise-free circuit. Therefore, any soft error reports should be examined and the cause isolated. 

If soft errors are reported while running a DMV11 on a fully loaded system (other devices being exer- 
cised simultaneously), they may be due to bus latency. This may be verified by running only the 
DMD*DEC/X1 1 module with only one DMV1 1 enabled. If the soft errors cease, a latency condition is 
indicated. 

If soft errors persist while running only the DMD*DEC/X11 module, the DMV11 device diagnostics 
should be run. The problem could be a faulty DMV11 or cable. 

SRI and SR2 (bit 0) may be used in the isolation process. If SRI =0 and SR2= 1, DEC/X1 1 does not 
set line unit loopback but it uses an external turnaround. By running with SRI =0 and SR2=0, a TTL 
loopback is performed, eliminating the possibility of the cable/turnaround connector being faulty. 

TTL loopback eliminates the level converters and the integral modem. The bit rate selected is 56K b/s 
using the internal clock. 
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APPENDIX A 
DDCMP IN A NUTSHELL 



A.l DDCMP 

The Digital Data Communications Message Protocol (DDCMP) provides a data link control procedure 
that ensures a reliable data communication path between communication devices connected by data 
links. DDCMP has been designed to operate over full- and half-duplex synchronous and asynchronous 
channels in both point-to-point and multipoint modes. It can be used in a variety of applications such as 
distributed computer networks, host front-end processors, remote terminal concentrators, and remote 
job entry-exit systems. 

A. 1.1 Controlling Data Transfers 

The DDCMP message format is shown in Figure A-1. Three control characters are provided in 
DDCMP to differentiate between the three possible types of messages: 

• SOH - Data message follows, 

• ENQ - Control message follows, 

• DLE - Maintenance message follows. 

Note that the use of a fixed-length header and message size declaration obviates the requirement for 
extensive message and header delimiter codes. 



SYN 



SYN 



SOH 


COUNT 


FLAG 


RESPONSE 


SEQUENCE 


ADDRESS 


CRC-1 


DATA 


CRC-2 


14 BITS 


2 BITS 


8 BITS 


8 BITS 


8 BITS 


1 6 BITS 


(ANY NUMBER OF 8-BIT 
CHARACTERS UP TO 2 14 ) 


1 6 BITS 















Figure A-1 DDCMP Data Message Format 



A. 1.2 Error Checking and Recovery 

DDCMP uses a 16-bit cycle redundancy check (CRC-1 6) for detecting transmission errors. When an 
error occurs, DDCMP sends a separate negative acknowledge (NAK) message. DDCMP does not re- 
quire an acknowledgement message for all data messages. The number in the response field of a normal 
header or in either the special NAK or acknowledge (ACK) control message specifies the sequence 
number of the last good message received. For example, if messages 4, 5, and 6 have been received 
since the last time an acknowledgement was sent and message 6 is bad, the NAK message specifies 
number 5 which says "messages 4 and 5 are good and 6 is bad." When DDCMP operates in full-duplex 
mode, the line does not have to be turned around; the NAK is simply added to the sequence of messages 
for the transmitter. 

When a sequence error occurs in DDCMP, the receiving station does not respond to the message. The 
transmitting station detects, from the response field of the messages it receives (or via timeout), that 
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the receiving station is still looking for a certain message and sends it again. For example, if the next 
message the receiver expects to receive is 5, but receives 6 instead, the receiver does not change the 
response field (which contains a 4) of its data messages. The receiver will say, "I accept all messages up 
through message 4 and I'm still looking for message 5." 

A. 1.3 Character Coding 

DDCMP uses ASCII control characters for SYN, SOH, ENQ and DLE. The remainder of the mes- 
sage, including the header, is transparent. 

A. 1.4 Data Transparency 

DDCMP defines transparency by use of a count field in the header. The header is of a fixed length. The 
count in the header determines the length of the transparent information field, which can be from 1 to 
16,383 bytes long. To validate the header and count field, it is followed by a CRC-16 field; all header 
characters are included in the CRC calculation. Once validated, the count is used to receive the data 
and to locate the second CRC-16, which is calculated on the data field. Thus, character stuffing is 
avoided. 

A. 1.5 Data Channel Utilization 

DDCMP uses either full-duplex or half-duplex circuits at optimum efficiency. In the full-duplex mode, 
DDCMP operates as two independent one-way channels, each containing its own data stream. The only 
dependency is the acknowledgements which must be sent in the data stream in the opposite direction. 

Separate ACK messages are unnecessary, therefore, reducing the control overhead. Acknowledgements 
are simply placed in the response field of the next data message for the opposite direction. If several 
data messages are received correctly before the terminal is able to send a message, all of them can be 
acknowledged by one response. Only when a transmission error occurs, or when traffic in the opposite 
direction is light (no data message to send), is it necessary to send a special NAK or ACK message, 
respectively. 

In summary, DDCMP data channel utilization features include: 

1. The ability to run on full-duplex or half-duplex data channel facilities, 

2. Low control character overhead, 

3. No character stuffing, 

4. No separate ACKs when traffic is heavy; this saves on extra sync-characters and inter- 
message gaps, 

5. Multiple acknowledgements (up to 255) with one ACK, and 

6. The ability to support point-to-point and multipoint lines. 
A.2 PROTOCOL DESCRIPTION 

DDCMP is a very general protocol; it can be used on synchronous or asynchronous, half-duplex or full- 
duplex, serial or parallel, and point-to-point or multipoint systems. Most applications involving protocols 
are half-duplex or full-duplex transmissions in a serial synchronous mode; that operating environment is 
emphasized in the following description. 

The header is the most important part of the message because it contains the message sequence num- 
bering information and the character count, the two most important features of DDCMP. Because of 
the importance of the header information, it merits its own CRC blockcheck, indicated in Figure A-2 as 
CRC-1. Messages that contain data, rather than just control information, have a second section which 
contains any number of 8-bit characters (up to a maximum of 16,383) and a second CRC (indicated in 
Figure A-2 as CRC-2). 
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NOTE 1 



SYN 



SYN 

















INFORMATION 




CLASS 


COUNT 


FLAG 


RESPONSE 


SEQUENCE 


ADDRESS 


CRC 1 


ANY NUMBER 


CRC 2 


14 BITS 


2 BITS 


8 BITS 


8 BITS 


8 BITS 


16 BITS 


OF 8-BIT 
CHARACTERS 


1 6 BITS 




SOH - DATA MESSAGES 

CKIrt ( ACKNOWLEDGEMENT 
ENQ I 

I NEGATIVE ACKNOWLEDGE 



XXXXXXXX XXXXXXXXXXXXXX XX xxxxxxxx xxxxxxxx xxxxxxxx 

10000001 CHARACTER COUNT QS RESP # MESSAGE* ADDRESS 

00000101 00000001000000 QS RESP # 00000000 ADDRESS 

00000101 00000010 QS RESP # 00000000 ADDRESS 



REASONS: 



BCC HEADER ERROR 000001 

BCC DATA ERROR 000010 

REP RESPONSE 00001 1 

BUFFER UNAVAILABLE 001000 

RECEIVER OVERRUN 001001 

MESSAGE TOO LONG 010000 

HEADER FORMAT ERROR 010001 



REPLY MESSAGE 00000101 

ENQ START MESSAGE 00000101 

START ACKNOWLEDGEMENT 00000101 

DLE MAINTENANCE MESSAGE 10010000 



00000011000000 QS 00000000 LSTMESS* ADDRESS 

00000110000000 11 00000000 00000000 ADDRESS 

00000111000000 11 00000000 00000000 ADDRESS 

CHARACTER COUNT 11 00000000 00000000 ADDRESS 



NOTES: 

1. ONLY THE DATA MESSAGE AND THE MAINTENANCE MESSAGE HAVE CHARACTER COUNTS, SO 
ONLY THESE MESSAGES HAVE THE INFORMATION AND CRC2 FIELDS SHOWN IN THE MESSAGE 
FORMAT DIAGRAM ABOVE. 

2. "RESP #" REFERS TO RESPONSE NUMBER. THIS IS THE NUMBER OF THE LAST MESSAGE 
RECEIVED CORRECTLY. WHEN USED IN A NEGATIVE ACKNOWLEDGE MESSAGE, IT IS ASSUMED 
THAT THE NEXT HIGHER NUMBERED MESSAGE WAS NOT RECEIVED, WAS RECEIVED WITH 
ERRORS, OR WAS UNACCEPTED FOR SOME OTHER REASON. SEE "REASONS." 

3. "MESSAGE*" IS THE SEQUENTIALLY ASSIGNED NUMBER OF THIS MESSAGE. NUMBERS ARE 
ASSIGNED BY THE TRANSMITTING STATION MODULO 256; I.E., MESSAGE 000 FOLLOWS 255. 

4. "LSTMESS#" IS THE NUMBER OF THE LAST MESSAGE TRANSMITTED BY THE STATION. SEE THE 
TEXT DISCUSSION OF REP MESSAGES. 

5. " ADDRESS" IS THE ADDRESS OF THE TRIBUTARY STATION IN MULTIPOINT SYSTEMS AND IS 
USED IN MESSAGES BOTH TO AND FROM THE TRIBUTARY. IN POINT TO POINT OPERATION, A 
STATION SENDS THE ADDRESS "1" BUT IGNORES THE ADDRESS FIELD ON RECEPTION. 

6. "Q" AND "S" REFER TO THE QUICK SYNC FLAG BIT AND THE SELECT BIT. SEE TEXT. 

MK-2249 

Figure A-2 DDCMP Message Format in Detail 
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Before the message format is discussed in greater detail, the message sequencing system should be ex- 
plained because most of the header information is directly or indirectly related to the sequencing oper- 
ation. 

In DDCMP, any pair of stations that exchange messages with each other number those messages se- 
quentially starting with message number one. Each successive data message is numbered using the next 
number in sequence, modulo 256. Thus, a long sequence of messages would be numbered 1, 2, 3,. ..254, 
255, 0, 1 ,...255. The first message sequence always starts with a number 1, and every sequence there- 
after begins with a 0. The numbering applies to each direction separately. For example, station A might 
be sending its messages 6, 7, and 8 to station B, while station B is sending its messages 5, 6, and 7 to 
station A. Thus, in a multipoint configuration where a control station is engaged in two-way commu- 
nication with ten tributary stations, there are 20 different message number sequences involved - one 
sequence for messages from each of the ten tributaries to the control station, and one sequence for 
messages from the control station to each of the ten tributaries. 

Whenever a station transmits a message to another station, it assigns its next sequential message num- 
ber to that message and places that number in the sequence field of the message header. In addition to 
maintaining a counter for the sequentially numbered messages which it sends, the station also maintains 
a counter of the message numbers received from the other station. It updates that counter whenever a 
message is received with a message number exactly one higher than the previously received message 
number. The contents of the received message counter are included in the response field of the message 
being sent, to indicate to the other station the highest sequenced message that has been received. 

When a station receives a message containing an error, that station sends a negative acknowledge 
(NAK) message back to the transmitting station. DDCMP does not require an acknowledgement for 
each message, as the number in the response field of a normal header (or in either the special NAK or 
positive acknowledgement message ACK) specifies the sequence number of the last good message re- 
ceived. 

When a station receives a message that is out of sequence, it does not respond to that message. The 
transmitting station detects this from the response field of the messages which it receives; if the reply 
interval expires before the transmitting station receives an acknowledgement, the transmitting station 
sends a REP (reply) message. The REP message contains the sequence number of the most recent 
unacknowledged message sent to the remote station. If the receiving station has correctly received the 
message referred to in the REP message (as well as the messages preceding it), it replies to the REP by 
sending an ACK. If it has not received the message referred to in sequence, it sends a NAK containing 
the number of the last message that it did receive correctly. The transmitting station then retransmits 
all data messages after the message specified in the NAK. 

The numbering system for DDCMP messages permits up to 255 unacknowledged messages out- 
standing; a useful feature when working on high-delay circuits such as those using satellites. However, 
the DMV11 limits the maximum number of unacknowledged messages outstanding to be 127. 

A.3 MESSAGE FORMAT 

With the above background, it is now time to explore the various DDCMP message formats in full 
detail, as shown in Figure A-2. The first character of the message is the class of message indicator, 
represented in ASCII with even parity. There are three classes of messages; data, control, and mainte- 
nance. These are indicated by class of message indicators SOH, ENQ, and DLE, respectively. The next 
two characters of the message are broken into a 14-bit field and a 2-bit field. The 14-bit field is used in 
data and maintenance messages to indicate the number of characters that follow the header CRC field 
and form the information part of the message. In control messages, the first eight bits of the 14-bit field 
are used to designate what type of control message it is; the last six bits are generally filled with zeros. 
The exception is in NAK messages where the last six bits are used to specify the reason for the NAK. 
The 2-bit field contains the quick-sync and select flags. 
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The quick-sync flag is used to inform the receiving station that the message will be followed by sync- 
characters; the receiver may wish to set its associated synchronous receiver hardware into sync-search 
mode and sync-strip mode. This reestablishes synchronization and syncs are discarded until the first 
character of the next message arrives. The purpose of this is to permit the receiving station to engage 
any hardware sync-stripping logic it might have and prevent it from filling its buffers with sync-charac- 
ters. The select flag is used to control link management in half-duplex or multipoint configurations 
where transmitters need to get turned on and off. 

Link management is the process of controlling the transmission and reception of data on links where 
there may be two or more transmitters and/or receivers actively connected to the same signal channels. 
This is true of half-duplex point-to-point links, as well as full- and half-duplex multipoint links. On half- 
duplex links, only one transmitter may be active at a time; on full-duplex links, only one slave trans- 
mitter may be active on the link at a time. 

A station on such a link may transmit when it has been selected or granted ownership of the link. This 
ownership is passed by use of the select flag existing in all messages. A select flag set in a received 
message allows the addressed station to transmit after completing reception of the message. The select 
flag also means that the transmitter ceases transmitting after the message is sent. 

The response fiel'd contains the number of the last message correctly received. This field is used in data 
messages and in the positive and negative acknowledge types of control messages. Its function should be 
evident from the preceding discussion of sequence control. 

The sequence field is used in data messages and in the REP type of control message. In a data message, 
it contains the sequence number of the message as assigned by the transmitting station. In a REP mes- 
sage, it is used as part of the question, "Have you received all messages up through message number 
(specify) correctly?" 

The address field is used to identify the tributary station in multipoint networks and is used in messages 
both to and from the tributary. In point-to-point operation, each station uses an address of 1. 

In addition to the positive and negative acknowledgement and REP types of control messages, there are 
also start and start acknowledge control messages. These are used to place the station which receives 
them in a known state. In particular, they initialize the message counters, timers, and other counters. 
The start acknowledge message indicates that this has been accomplished. 

Figure A-2 also shows the maintenance message. This is typically a bootstrap message containing load 
programs in the information field. A complete treatment of maintenance messages and start-up pro- 
cedures is beyond the scope of this book. 

NOTE 

Refer to the DDCMP specification order (AA- 
D599A-TC) for a complete detailed description of 
DDCMP. 
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APPENDIX B 
FLOATING DEVICE 
AND VECTOR ADDRESSES 



B.1 FLOATING DEVICE ADDRESSES 

UN I BUS and LSI-1 1 addresses, starting at 760010 and continuing through 763776, are designated as 
floating device addresses (see Figure B-1). These are used as register addresses for communications 
(and other) devices interfacing with the PDP-11 (refer to Table B-1). 



NOTE 

Some devices are not supported by LSI-1 1; however, 
the same scheme applies. That is, gaps are provided 
as appropriate. The convention for assigning these 
addresses is as follows: 



A gap of 10g must be left between the last address of one device type and the first address of the next 
device type. The first address of the next device type must start on a modulo 10s boundary. The gap of 
108 must a l s0 b e left for devices that are not installed but are skipped over in the priority ranking list. 
Multiple devices of the same type must be assigned contiguous addresses. Reassignment of device types 
already in the system may be required to make room for additional ones. 



B.2 FLOATING VECTOR ADDRESSES 

Vector addresses, starting at 300 and proceeding upward to 777, are designated as floating vectors. 
These are used for communications (and other) devices that interface with the PDP-1 1 and VAX-1 1. 
Multiple devices of the same type would be assigned vectors sequentially (refer to Table B-2). 



NOTE 

Some devices are not supported by LSI-1 1; however, 
the same scheme applies. Vector size is determined 
by the device type. 



There are no gaps in floating vectors unless required by physical hardware restrictions (in data commu- 
nications devices, the receive vector must be on a zero boundary and the transmit vector must be on a 
48 boundary). 
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777 777 



2K 
WORDS 



DIGITAL EQUIPMENT 
CORPORATION 

(FIXED ADDRESSES) 



1K 
WORDS 



DR1 1-C 
t 

USER ADDRESSES 



770 000 
767 777 



764 000 
763 777 



1K 
WORDS 



FLOATING ADDRESSES 



DIGITAL EQUIP CORP (DIAGNOSTICS) 



760 010 
760 006 
760 000 
757 777 



80 
VECTORS 



48 

VECTORS 



FLOATING VECTORS 



TRAP & INTERRUPT 
VECTORS 



001 000 
000 777 



000 300 
000 277 



000 000 



MK-2190 



Figure B-l UNIBUS and LSI-1 1 Address Map 
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Table B-l Floating CSR Address Devices 







Decimal 


Lictai 


Rank 


vr|f HUH 




ivioauius 


1 
1 


LfJ l l 


A 


1U 


Z 


utn i i 


O 
O 


zuy 


-5 
J 




A 


1 o 
1U 


A 


ni n i 


A 


i n 


J 


ni ipi 1 


4 

*T 


1 n 

1U 


A 




A 

*T 


10 
1 u 


7 


DMC1 1 /DMR 1 1 


4 

t 


1 


Q 



U/Lll ailQ V 1 


A 


i n 
1 u 


Q 




4 


1U 


10 


I PP1 1 


4 


10 


1 1 
i i 


VUV) 1 
V 1V1 V L 1 


4 


i n 

1U 




V 1V1 V J l 






?o+ 


1 \ 


HWR7H 
UWt\/U 


4 


i n 


1 4 


PI 11 onrl P 1 VI 1 

i\Li i anu i\L v 1 1 


4 


1 (extra only) 


1 C 

1 D 


T P A 1 1 V 




o 


20 (extra only) 


16 


KW11-C 


4 


10 


17 


Reserved 


4 


10 


18 


RX11 


4 


10 (extra only) 


19 


DR11-W 


4 


10 


20 


DR11-B 


4 


10 (after second) 


21 


DMP11-AD 


4 


10 


22 


DPV11 


4 


10 


23 


ISB11 


4 


10 


24 


DMV11-AD 


8 


20 



*DZ1 IE and DZ1 IF are dual DZ1 Is and are treated by the algorithm as two DZ1 Is. 
tStarting CSR address must be an even multiple of 20 (octal). 



Table B-2 Floating Interrupt Vector Devices 







Decimal 


Octal 


Rank 


Option 


Size 


Modulus 


1 


DC11 


4 


10 


2 


KL11 (extra) 


4 


10* 


2 


DL11-A (extra) 


4 


10* 


2 


DL11-B (extra) 


4 


10 


3 


DP11 


4 


10 


4 


DM1 1-A 


4 


10 


5 


DN11 


2 


4 


6 


DM11-BB 


2 


4 


7 


DH 1 1 modem control 


2 


4 


8 


DR11-A 


4 


10* 


9 


DR11-C 


4 


10* 



♦The vector for the device of this type must always be on a 10s boundary. 
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Table B-2 Floating Interrupt Vector Devices (Cont) 







Decimal 


Octal 


Rank 


Option 


Size 


Modulus 


10 


PA6 1 1 (reader & punch) 


8 


10* 


11 


LPD11 


4 


10 


12 


DT11 


4 


10* 


13 


DX11 


4 


10* 


14 


DL11-C 


4 


10* 


14 


DL11-D 


4 


10* 


14 


DL11-E 


4 


10* 


15 


DJ11 


4 


10* 


16 


DH11 


4 


lOt 


17 


GT40/VSV11 


8 


10 


18 


LPS 11 


12 


10* 


19 


DQ11 


4 


rot 


20 


KW11-W 


4 


10 


21 


DU11 


4 


10* 


22 


DUP1 1 


4 


10* 


23 


DV and modem control 


6 


10 


24 


LK11-A 


4 


10 


25 


DWUN 


4 


10 


26 


DMC11/DMR11 


4 


10* 


27 


DZ11/DZ32/DZV11 


4 


10* 


28 


KMC 11 


4 


10 


29 


LPP11 


4 


10 


30 


VMV21 


4 


10 


31 


VMV31 


4 


10 


32 


VTV01 


4 


10 


33 


DWR70 


4 


10* 


34 


RL11/RLV11 


2 


4 


35 


TS11 


2 


4 (after the first) 


36 


LPA11-K 


4 


10 


37 


IP11/IP300 


2 


4 


38 


KW11-C 


4 


10 


39 


RX11/RX211 


2 


4 (after the first) 


40 


DR11-W 


2 


4 


41 


DR11-B 


2 


4 (after the first) 


42 


DMP11-AD 


4 


10 


43 


DPV11 


4 


10 


44 


ML11 


2 


4 (MASSBUS device) 


45 


ISB11 


4 


10 


46 


DMV11-AD 


4 


10 



*The vector for the device of this type must always be on a 10s boundary. 

tThese devices can have either a M7820 or M7821 interrupt control module. However, it should always 
be on a 1 0s boundary. 
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B.3 EXAMPLES OF DEVICE AND VECTOR ADDRESS ASSIGNMENT 

This example has three devices that require device and vector address assignment in the floating ad- 
dress space. The devices are: 



• 1 RLV11 

• 2 DPV1 Is 

• 1 DMV11 



Device 
(Option) 



RLV11 



DPV11 
DPV11 



DMV11 



Device 
Address 

760010 
760020 
760030 
760040 
760050 
760060 
760070 
760100 
760110 
760120 
760130 
760140 
760150 
760160 
760170 

760200 
760210 
760220 
760230 
760240 
760250 
760260 
760270 
760300 
760310 

760320 
760340 
760360 



Vector 
Address 



300 



310 
320 



330 



Comment 

Gap left for DJ1 1 

Gap left for DH11 

Gap left for DQ11 

Gap left for DU11 

Gap left for DUP11 

Gap left for LK11A 

Gap left for DMC1 1/DMR1 1 

Gap left for DZ11/DZV11 

Gap left for KMC 11 

Gap left for LPP11 

Gap left for VMV21 

Gap left for VMV31 

Gap left for DWR70 

First and only RLV11 

Gap left between RLV1 1 and next 

device 

Gap left for LPA 11 -K 
Gap left for KW11-C 
Reserved 
Gap left for RX11 
Gap left for DR11-W 
Gap left for DR11-B 
Gap left for DMP11 
First DPV 11 
Second DPV 11 

Gap left between DPV1 1 and next 
device 

Gap left for ISB11 

First and only DM VI 1 

Gap left after last device, in this 

case the DM VI 1, to indicate that no 

other devices follow 



B-5 



APPENDIX C 

MODEM CONTROL REGISTER FORMATS 



C.l MODEM CONTROL REGISTER FORMATS 

The modem signals made available by the DM VI 1 can be examined or modified by the user program if 
needed. This supplies the flexibility needed to meet the various modem interface requirements of dif- 
ferent countries. 

READ MODEM STATUS 

BSEL4: 

Bit Name Description 

CARRIER Received line signal detector, commonly referred to as carrier de- 

tect, indicates that there is an appropriate audio tone being re- 
ceived from the remote modem. Typically, in full- and half-dupl- 
ex applications, carrier detect is on whenever the 
communications line is intact and the remote modem has the sig- 
nal request to send asserted (the modem is transmitting). This 
signal is also applicable to the DMV11 integral modem. 

ALWAYS READ AS ZERO. 

This signal is generated by the local modem to indicate whether 
or not it is ready to transmit data. Clear to send is the local 
modem's response to the asserting of request to send. This signal 
has a slightly different meaning with different modems. With 
some modems it indicates that the carrier is being received from 
the remote modem, and, therefore, is an indication that a suitable 
communications channel exists. 

This signal indicates that the modem is ready to operate. The ON 
condition indicates that the local modem is connected to the com- 
munications line and is ready to exchange further control signals 
with the DMV11. The OFF condition indicates that the local 
modem is not ready to operate. This signal, when implemented by 
the modem, is used by the DMV11 to detect either a power-off 
condition or a cable-related modem malfunction. 

This signal, when asserted, indicates that the DMV11 is in the 
half-duplex mode. This means that the DMV11 is connected to a 
communications line designed for transmission in either direc- 
tion, but not in both directions simultaneously. When cleared, it 
implies full-duplex operation which is two-way independent trans- 
mission in both directions. 



NOT USED 
CLEAR TO SEND 



MODEM READY 



HALF-DUPLEX 
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Bit Name Description 



5 REQUEST TO SEND This signal serves to control the data channel transmit function of 

the local modem, and on a half-duplex channel, to control the di- 
rection of data transmission of the local modem. On a full-duplex 
channel, the ON condition maintains the modem in the transmit 
mode, and the OFF condition maintains the modem in the non- 
transmit mode. On a half-duplex channel, the ON condition 
maintains the modem in the transmit mode and inhibits the re- 
ceive mode. The OFF condition maintains the modem in the re- 
ceive mode. A transition from OFF to ON instructs the modem to 
enter the transmit mode. The modem responds by taking such ac- 
tion as may be necessary and indicates completion of such actions 
by asserting clear to send, thereby, indicating to the DM VI 1 that 
data may be transferred across the communications channel. A 
transition from ON to OFF instructs the modem to complete the 
transmission of all data that was previously transferred to the 
modem and then assume a nontransmit or receive mode, which- 
ever is appropriate. The modem responds to this instruction by 
turning OFF the signal clear to send when it is again prepared to 
respond to a subsequent ON condition of request to send. 



6 DATA TERMINAL This signal controls the switching of the local modem to and from 

READY the communications line. When asserted, this signal serves to in- 

form the local modem that the DMV1 1 is ready to operate. This 
signal also prepares the modem for connection to the commu- 
nications line and maintains this connection as long as it is ON. 
When turned OFF, this signal causes the local modem to dis- 
connect after all data previously transferred to the modem has 
been transmitted. This signal can be used by the local modem to 
detect a power-off condition in the DMV11 or a cable-related 
modem malfunction. 



7 RING This signal indicates whether an incoming call signal is being re- 

ceived by the local modem. When ON, this signal indicates that 
an incoming call (ringing) signal is being received by the local 
modem. The ON state of ring must appear approximately at the 
same time as the ON segment of the ringing cycle (during rings) 
on the communications line. The OFF condition must be main- 
tained during the OFF segment of the ringing cycle (between 
rings) and at all other times that ringing is not being received. 
This signal is not affected by the state of data terminal ready. 



READ MODEM STATUS 
BSEL5 

Bit Name Description 

MODE This bit indicates the operational mode of the line unit. A one in- 

dicates character-oriented protocol operation, and a zero in- 
dicates bit-oriented protocol operation. The DMV11 initializes 
this bit to one. 
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Bit Name Description 

1 NOT USED ALWAYS READ AS ZERO. 

2 TEST MODE This signal indicates whether or not the local modem is in a test 

condition. (This signal applies only to modems that support this 
feature.) When in the ON condition, this signal indicates to the 
DM VI 1 that the local modem has been placed in a test condition. 
The ON condition can also be in response to either local or re- 
mote activation by means of any other modem test condition. Ac- 
tivation of a telecommunications network test condition (for ex- 
ample, facility loopback) that is known to the modem can also 
cause this signal to be ON. In the OFF condition, this signal in- 
dicates that the modem is not in the test mode and is available for 
normal operation. 



3 NOT USED ALWAYS READ AS ZERO 

4 NOT USED ALWAYS READ AS ZERO 

5 NOT USED ALWAYS READ AS ZERO 

6 NOT USED ALWAYS READ AS ZERO 

7 NOT USED ALWAYS READ AS ZERO 

WRITE MODEM CONTROL 

BSEL4 

Bit Name Description 

NOT USED 

1 SELECT STANDBY Defaulted to by DM VI 1 hardware. 

2 MAINTENANCE Defaulted to by DMV11 hardware. 
MODE 2 

3 MAINTENANCE Defaulted to by DM VI 1 hardware. 
MODE 1 

4 HALF-DUPLEX The DMV1 1 uses this bit to place the line unit into the half-dupl- 



ex mode. The user program cannot set or clear this bit. The 
DMV11 can change line characteristics only through the mode 
definition command. The DMV1 1 is equipped with a software in- 
terlock that prevents simultaneous transmission and reception 
when in the half-duplex mode. While the transmitter is trans- 
mitting, the receiver is disabled from receiving data via a hard- 
ware interlock. 



5 SELECT This signal is used to select the transmit and receive frequency 

FREQUENCY bands of a modem. In the ON condition, the higher frequency 



Bit Name Description 

band is selected for transmission to the communications channel, 
and the lower frequency band is selected for reception from the 
communications channel. When OFF, the lower frequency band 
is selected for transmission to the communications channel, and 
the higher frequency band is selected for reception from the com- 
munications channel. 

NOTE 

The modem, if it supports select frequency, must be 
set up to ignore this signal from DMV11. 

6 DATA TERMINAL This signal controls switching of the local modem to and from the 
READY communications line. When asserted, this signal serves to inform 

the local modem that the DM VI 1 is ready to operate. This signal 
also prepares the modem for connection to the communications 
line and maintains this connection as long as it is ON. When 
turned OFF, this signal causes the local modem to disconnect af- 
ter all data previously transferred to the modem has been trans- 
mitted. This signal can be used by the local modem to detect a 
power-off condition at the DMV11 or a cable-related modem 
malfunction. 

7 NEW SIGNAL This signal determines whether or not the local modem will rapid- 

ly respond to new data on the communications line. This signal is 
used at control stations in multipoint networks where the remote 
modems operate in switched-carrier mode. This incoming signal 
to the control station appears as a series of short message bursts 
transmitted by each tributary as it responds to the poll from the 
control station. In order to permit rapid accommodation to sig- 
nals from several tributaries appearing in quick succession, the 
control station informs the local modem when a new signal is 
about to begin by asserting polling for a brief interval. For syn- 
chronous systems, clock timing on the incoming message varies 
from message to message because the remote modems are in no 
way synchronized to each other. If the time interval between mes- 
sages is too short, the clock holdover after the end of one message 
may preclude rapid synchronization on the following message. 
The use of this signal allows the control station to reset the 
modem receiver timing recovery circuit, enabling it to respond 
more quickly to the line signal present after polling has been 
turned OFF. This signal applies only to modems that support pol- 
ling. 

C.2 RS-449 VERSUS RS-232-C 

The most common interface standard in use during recent years is RS-232-C. However, when used in 
modern communications systems it has critical limitations; the most serious being speed and distance. 

For this reason, the interface standard RS-449 was developed to replace RS-232-C. This standard main- 
tains a degree of compatibility with RS-232-C to accommodate an upward transition to RS-449. 

The most significant difference between RS-449 and RS-232-C is the electrical characteristics of sig- 
nals used between the data communications equipment (DCE) and the data terminal equipment 
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(DTE). The RS-232-C standard specifies only unbalanced circuits, whereas, RS-449 specifies both bal- 
anced and unbalanced circuits. The specifications for these two circuit types supported by RS-449 are 
contained in EIA standards RS-422-A for balanced circuits and RS-423-A for unbalanced circuits. 
These new standards permit greater transmission speeds and allow greater distance between the DTE 
and DCE. The maximum transmission speeds supported by RS-422-A and RS-423-A specified circuits 
vary with circuit length. The normal transmission speed limits are 20K b/s for RS-423-A at 61 m (200 
feet) and 2M b/s for RS-422-A also at 61 m (200 feet). These normal transmission speeds can be varied 
by tradeoffs between speed and distance. 

Another major difference between RS-449 and RS-232-C is the specification of two new connectors to 
accommodate the leads required to support additional circuit functions and the balanced interface cir- 
cuits. One connector is a 37-pin Cinch used to accommodate the majority of data communications appli- 
cations. The other is a 9-pin cinch for applications requiring secondary channel functions. Some of the 
new circuits implemented by RS-449 support local and remote loopback testing and standby channel 
selection. 

The transition from RS-232-C to RS-449 will not happen immediately. Therefore, applications that re- 
quire connection between RS-232-C and RS-449 interfaces must adhere to the limitations of RS-232-C, 
which specifies a normal transmission speed of 20K b/s at a maximum distance of 15.2 m (50 feet). 

DMV11 does not support RS-422-A balanced circuits. 
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APPENDIX D 
MODEM CONTROL 



D.l MODEM CONTROL 

There are two levels of modem control available to the DM VI 1. The first level is provided by the hard- 
ware, and the second by the DMV11 microcode. 

D.l.l Hardware Modem Control 

The DMV11 provides the following modem control function: 

• Prevention of simultaneous transmission and reception in half-duplex mode. 

Half-Duplex Mode - When set, HALF-DUPLEX specifies that the DMV1 1 is in the half-duplex mode. 
In half-duplex mode, a hardware interlock prevents the DMV1 1 from transmitting and receiving simul- 
taneously. 

NOTE 

This hardware lockout prevents the DMV11 from 
being used in the half-duplex mode on a full-duplex 
modem with the continuous carrier option installed. 

D.l. 2 Modem Control Implemented by the DMV11 Microcode 

The modem control signals implemented by the DMV11 are: 

• Modem ready (data set ready), 

• Request to send/clear to send, 

• Carrier, 

• Data terminal ready, and 

• Auto answer. 

Each of these signals are outlined in Table D-1. 

Once modem ready goes ON, the DM VI 1 reports any transition from ON to OFF to the user program 
by issuing a control response containing the code for the system-event modem disconnect. The micro- 
code tests that modem ready is OFF for 10 ms. Transmission is initially inhibited by the microcode by 
interlocking the signals modem ready and request to send. 

Whenever the signal carrier detect is dropped by the modem for greater than 1.28 seconds, the user 
program is notified by a control response containing the code for the system event modem carrier loss. 

Diagrams are used in the discussion of modem control functions. Refer to Figure D-1 as an aid in inter- 
preting these diagrams. The flow depicted by the diagrams (Figures D-2 through D-8) describes the pro- 
cessing of EIA modem control signals by the DMV1 1. Each diagram represents a serial flow for a spe- 
cific modem control function. However, the functions performed, as represented by each diagram, are 
performed in parallel. The readable and writeable modem signals listed on the diagram for modem sta- 
tus can be read and written through the control command using the request keys read modem status 
and write mode control. 
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Table D-l DMV11 Modem Control Functions 



Signal 

Data Set Ready- 
Modem Ready: 



Description 

Software interlock prevents the DMV1 1 from transmitting if DSR is not 
returned. If DSR drops (meaning that it once was asserted) for a period 
of 10 ms, the transmitter and receiver are resynchronized, the transmitter 
and receiver sections of the microcode are reset to the idle state to allow 
the user to return buffers, DTR is then dropped to clear the line (see 
DTR for reasserting conditions), and the user is then notified of the DSR 
drop via a control-out for disconnect. 

Software interlock preventing the DMV11 from transmitting if DSR is 
not returned: If the DMV11 has been instructed by the user to start up 
the communications line, and DSR is not asserted, the DMV11 does not 
transmit. There is no timer started for the first assertion of DSR. It is the 
responsibility of the user to ensure that the modem is plugged in. Also, if 
the modem is a dial-up modem, the user should make sure that the num- 
ber is dialed. In most cases the start command is issued with the intent of 
waiting for an incoming call. In this case, the timer value is arbitrary so 
that it has been left up to the user software to determine this timeout. If 
data terminal ready (DTR) is not asserted because of a past error condi- 
tion that caused the dropping of DTR (that is, disconnect), the user pro- 
gram may assert DTR via the write modem command to enable transmis- 
sion. 



Request to Send/ 
Clear to Send: 



For all applications: Before RTS is asserted (if already asserted this is 
bypassed) CTS is checked for the "ON" condition. If CTS is '*ON", a 
10-20 ms timer is started while waiting for CTS to drop. If CTS does not 
drop within the timer period, constant CTS is assumed and RTS is set. 

For all applications: Software interlock prevents transmission if CTS is 
not returned. IF CTS is not returned within 30 seconds (plus or minus 10 
ms), a disconnect control-out is queued with a CTS failure code in 
BSEL7. The transmitter and receiver are resynchronized, the transmitter 
and receiver sections of the microcode are reset to the idle state to allow 
the user to return buffers, and DTR is then dropped to clear the line. (See 
DTR for reasserting conditions). 

For all applications: During the time that RTS is set, every 10 ms CTS is 
checked for the "ON" condition. If CTS stays in the "OFF" condition for 
30 seconds (plus or minus 10 ms), a disconnect control out is queued with 
a CTS failure code in BSEL7. The transmitter and receiver are res- 
ynchronized, the transmitter and receiver sections of the microcode are 
reset to the idle state to allow the user to return buffers, and DTR is then 
dropped to clear the line. (See DTR for reasserting conditions). 

For all half-duplex applications: The setting of request to send is "AN- 
DED" with the half-duplex bit in the hardware to "blind" the receiver 
when transmitting. 
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Table D-l DMV11 Modem Control Functions (Cont) 



Signal Description 



Carrier: Software interlocks prevent transmission in half-duplex if carrier is in the 

"ON" condition. This prevents the DMV11 from running half-duplex on 
four-wire constant carrier modems. 

For all applications: Hardware interlock of carrier and the receiver clock 
stop the USYRT from receiving if carrier were to drop in the middle of a 
message. 

For all applications: If carrier "drops" while the DMV1 1 is in the process 
of receiving the carrier, the loss timer is started. If the carrier loss timer 
expires (1.28 second interval), the user is notified via a control-out for 
carrier loss. The receiver is then resynchronized and the receiver micro- 
code is reset to the waiting state for the next message. If the carrier loss is 
less than 1.28 seconds (carrier is reasserted before the timeout), the mes- 
sage being received is allowed to finish. If CRC errors are detected (nor- 
mal case), the protocol recovers from the failure. 

Data terminal ready: DM VI 1 clears DTR on a power-up bus initialization, and a master clear. 

This is a hardware function. DTR is not gated from the interface drivers 
when the DM VI 1 is placed in loopback mode. DTR is monitored by diag- 
nostics running in internal loopback to ensure that the microcode does not 
set it. 

When DTR is dropped because of errors, it is only reasserted if any of the 
following conditions exist: auto answer is enabled or remote load detect is 
enabled. The code is in the process of power-on boot or request boot. 

Auto Answer: This option is switch selectable. If enabled, the DMV1 1 asserts DTR and 

waits for modem ready (DSR). Because of the difference between 
modems in the U.S. and other countries, ring is not used as an indication 
that an incoming call has been established. As it stands, DSR is the in- 
dication that the call has been established. If a valid DDCMP message is 
not received within 30 seconds (plus or minus 10 ms) after a connection is 
established, DTR is dropped (hang up the phone). The connection is con- 
sidered to be established on assertion of carrier or clear to send. The 
transmitter and receiver are resynchronized, the transmitter and receiver 
sections of the microcode are reset to the idle state, and DTR is then reas- 
serted after DSR drops (or in 10 seconds whichever comes first). In this 
case the user is not notified of the cancelled call. An internal counter is 
incremented to log the incoming calls (latches at 256) and is available for 
reading by the user program. 
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CONDITIONS TO BE SATISFIED. IF CONDITIONS ARE NOT 
MET SERIAL FLOW DOES NOT CONTINUE. 



ACTIONS PERFORMED BY DMV11. 



ENTRY OR EXIT SYMBOLS 



MK-2657 

Figure D-l Flow Diagram Symbology 
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POWER ON 



[2.4] 



SYSTEM 
INITIALIZATION 



[2.4] 



DEVICE 

MASTER CLEAR [2,4] 



















POWER ON 


CLEAR DTR 


[2.5] 



(SWITCH) 



USER ISSUES 
MODE DEFN 
COMMAND 



MODE DEFINED 
IN SWITCHES 



BOOT 
BIT SET 



[2.6] 



[2.2] 



SET DTR 
SET CALTMR 
= ON 



[2.2] 



SET DTR 
SET CALTMR 
= ON 



SET P/MOP [2.3] 



USER REQUEST 
MODEM STATUS 
READ/WRITE 



CALTMR 
= ON 



[2.2] 



DSR = ON 







DSR = ON 







^ MODSTAT ^ ^ CALTMR ^ 



[2.1] 



DSR 
CD = 


= ON 
ON 






SCAN FOR 
REMOTE 
LOAD 
MESSAGE 







VALID 
MESSAGE 



\m l2 ' 3] 






SET P/MOP 





MESSAGE TO 
BE SENT 



DSR = ON TO 
OFF FOR 
10mSEC 



P/MOP = ON 



P/MOP = OFF 



^ TRANSMIT2 ^ 



NOTIFY USER OF 
DSR DROP 
DISCONNECT 
(CONTROL RESPONSE) 



^ RECEIVE ^ 



-0 



-*Q TRANSMIT ^ 



NOTES: 

[2.1] REMOTE LOAD DETECT IS A MAINT. DDCMP MESSAGE INITIATING A DOWN LINE LOAD. 
[2.2] CALTMR - (CALL TIMER): USED TO DETERMINE IF VALID MESSAGE IS RECEIVED. "ON" INDICATES TIMER 
RUNNING. 

[2.3] P/MOP • PRIMARY MAINTENANCE OPERATION PROTOCOL, REQUESTING REMOTE LOAD. 
[2.4] RUN COMPLETE MICRODIAGNOSTICS (MICROPROCESSOR AND LINE UNIT) 
[2.5] HARDWARE FUNCTION 

[2.6] INVOKE PRIMARY MOP BOOT (BIT FIVE, BSEL 1) 



Figure D-2 Modem Control (Start) 
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TRANSMIT 



HALF-DUPLEX 



FULL-DUPLEX 



RECEIVER NOT 
ACTIVE 



NO LINE ERRORS 
ENCOUNTERED 



LINE ERRORS 
ENCOUNTERED 



CARRIER WAIT 
TIMR — 1 SEC 



[3.1] 



CWTIMR 
= 



CD = OFF 



NOTIFY USER OF 

STREAMING 

STATION 



CD = OFF 



RTS=OFF 



RTS = ON 



CTS TIMER 20ms 



CTS=OFF 



CTS TMR=0 



CLEAR RTS 



ASSERT -RTS 



CTS TIMER — 1 SEC 



CTS TIMR 
30 SEC 



[3.2] 



CTS = 



CTSTMR = 



CTS=ON 



CTS TIMR=0 







NOTIFY USER 
OF CTS FAILURE 







SHUT DOWN 



TRANSMIT 



END OF TRANS 



CTS=OFF 



FDX 



HDX 



CTS TIMR 
10 SEC 



CLEAR RTS 



TIMR=0 



CTS=0N 











NOTIFY USER OF 
CTS FAILURE 







CANCEL CTS TIMR 



(shut down) 



NOTES: 

[3.1 ] CWTIMR -- CARRIER WAITTIMER. IT DETECTS THE CONDITION WHERETHE LINK WAS NOT RELINQUISHED IN 
TIME BY THE REMOTE END. 

[3.2] CTSTMR -- CLEAR TO SEND TIMER. TIME CLEAR TO SEND GOING AWAY WHEN DROPPING RTS BECAUSE OF LINE 

ERRORS. FALL-OUT COVERS CONDITION OF CONSTANT CTS MODEMS. 
[3.3] IN FULL DUPLEX MODE - DMP1 1 ASSERTS RTS CONSTANTLY. RTS IS DROPPED ONLY WHEN THERE ARE LINE 

ERRORS. 

[3.4] SOFTWARE INTERLOCK - CONDITION IS SWITCH SELECTABLE FOR CONSTANT CTS MODEMS. 



Figure D-3 Modem Control (Transmit) 
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LESS THAN 24 REQUEST 24 REQUEST REMOTE PROGRAM 
REMOTE PROGRAM LOAD LOAD MESSAGES SENT 
MESSAGES SENT . 



TIMER- 


-3 SEC 







TIMER = 



^ TRANSMIT ^ 



CLEAR DTR 






TIMER— 10 SEC 


1 





TIMER = 







SET DTR 



Figure D-4 Modem Control (Transmit 2) 
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HALF-DUPLEX FULL-DUPLEX 

TRANSMITTER NOT 
ACTIVE 



IN HALF DUPLEX, LINE UNIT . 

PROVIDES INTERLOCK TO " 

ENABLE RCV CLOCK ONLY IF * 

TRANSMITTER IS IDLE. CD ■ ON 

(RTS =OFF) SYNCED ON NEW 

FRAME 



START TO RECEIVE -i 



CD - OFF 



CD DROPPED IN THE 
MIDDLE OF DATA 
STREAM 



RESET CDTIMR 
TO 1.28 SEC 



CD - ON 



CDTIMR = 



NOTIFY USER OF 
CARRIER LOSS 
(CONTROL RESPONSE) 



RECEIVE 


RESET RECEIVER 









5 



Figure D-5 Modem Control (Receive) 
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t 

WRITE MODEM f6 
STATUS 1 " J 



[6.1] [6.2] 

READABLE MODEM SIGNALS: WRITEABLE MODEM SIGNALS: 

CARRIER DATA TERMINAL READY 

CLEAR TO SEND 

MODEM READY (DSR) 

HALF DUPLEX 

REQUEST TO SEND 

DATA TERMINAL READY 

RING 

TEST MODE 



MK-2702 

Figure D-6 Modem Control (Modem Status) 
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^ CALTMR 

3; 

START 65 SEC CALL TIMER 



VALID MESSAGE 
RECEIVED FOR 
THIS STATION 



SET CALTMR 
= OFF 



CALL TIMER =0 







CLEAR DTR 



RESET RECEIVER 
AND 

TRANSMITTER 



TIMER— 10 SEC 







TIMER = 



1 




SET DTR 



A ) NOTE: CALTMR = ON 



Figure D-7 Modem Control (Call Timer) 
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SHUT DOWN 







CLEA 
AND 


R DTR 
RTS 



RESET RECEIVER 
AND TRANSMITTER 



BOOTING 



REMOTE LOAD 
DETECT 



CALL TIMR=ON 



TIMR- 



10 SEC 



TIMR=0 



SET DTR 







Figure D-8 Modem Control (Shutdown) 
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What is your general reaction to this manual? In your judgement is it complete, accurate, well organized, 
well written, etc? Is it easy to use? 



What features are most useful?. 



What faults or errors have you found in the manual?. 
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